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Phase V represents digital Equipment Corporation's 
move from a proprietary network to Open Systems 
Interconnection (OSI), which is becoming the new 
international standard architecture. This book 
provides a solid understanding of DECnet’s 
underlying technology and how to choose the right 
network options for your needs. 


Carl Malamud, noted author on network 
architectures, familiarizes you with the architecture 
of DECnet/OSI Phase V. He discusses how DECnet 
compares to generic OSI protocols, how it compares 
to DECnet Phase IV, and how to integrate it with 
other network architectures. You'll learn about all 
aspects of data access, virtual terminals, 
messaging, naming and network management in 
DECnet. 


By learning how the pieces of a DECnet network fit 
sogether into a coherent whole, you'll be equipped to 
choose which pieces are appropriate for a particular 
environment. Specific topics covered include: 


= Operation of key data links such as Ethernet, FDDI, 
DDCMP, and X.25 

= Dynamic routing in OSI networks 

= Use of Enterprise-Wide Management Architecture 
(EMA) for managing various networks from one 
management platform 

= Support protocols such as synchronized time, 
remote procedure calls, and the Maintenance 
Operations Protocol 

= The Local Area Transport (LAT) architecture 

= The DNA Naming Service 


Analyzing DECnet/OS/ Phase V is essential reading 
for network implementors and designers, 
programmers who create software for network 
integration, and MIS managers. 
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Preface 


Analyzing DECnet/OSI Phase V is the second in a three volume series ana- 
lyzing networks. Whereas the first book, Analyzing Novell Networks, looked 
at the simplistic architecture of Novell’s NetWare, this one examines the 
opposite extreme—DEC’s Digital Network Architecture (DNA). The third 
volume, Analyzing Sun Networks, examines TCP/IP, NFS, and other protocols 
used in the Internet and in many distributed networks. 

Phase V of DNA is, without a doubt, one of the more complex network 
architectures ever invented. Incredible flexibility in network configuration 
and applications functionality have led to a degree of complexity surpassing 
even IBM’s System Network Architecture. This book takes the major pieces 
of that architecture (and several related architectures) and puts them into 
perspective, allowing the reader to see how an individual protocol fits into 
the larger picture. 

DECnet/OSI Phase V is really three different networks: a subset of OSI, a 
set of services backwardly compatible with DECnet Phase IV, and a new set 
of modern, proprietary services from Digital. We will see how these three 
parallel universes coexist in DECnet/OSI Phase V. We will also look at re- 
lated architectures, such as LAT, EMA, and MOP which fill in holes left by 
DECnet. A fourth architecture, TCP/IP, also plays a part in a heterogeneous 
DECnet environment. The reader is directed to Analyzing Sun Networks for 
more information on TCP/IP, NFS, SNMP, and related protocols. 

As we go to press, DECnet/OSI Phase V has resurfaced under a new 
name, Advantage-Networks. The name may be new, but the architecture is 
the same as described in this book. Why change a name if the underlying 
technology stays the same? This mystery can only be answered by the le 
gion of Digital marketing executives. 


Carl Malamud 
Carl@Malamud.Com 
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Introduction 


This is a book about a hybrid network architecture, Digital’s DECnet/OSI 
Phase V. DECnet is an implementation of Digital’s own proprietary net- 
work architecture, the Digital Network Architecture (DNA). DNA has gone 
through four “Phases” with Phase IV being the most recent. In Phase V, 
Digital took the Phase IV base and added a variety of OSI protocols, new 
proprietary protocols, and a few de facto standards. This mix of open and 
proprietary protocols is bundled together under the umbrella of Phase V. 

Open protocols means the specifications are published in sufficient detail 
to allow other vendors to provide their own implementations. Many open 
protocols that Digital is using come from the Open Systems Interconnection 
(OSD) protocol suite. Examples of protocols used in DECnet/OSI Phase V are 
the network layer packet format (ISO 8473) and the File Access, Transfer, 
and Management (FTAM) standards for data access. 

OSI is one of those truth and beauty concepts: nobody does all of OSI; 
instead, pieces are selected, as in the case of a Government OSI Profile (GO- 
SIP), a subset of OSI used by governments to establish procurement require- 
ments. By using GOSIP as a guide to procurement, the government is able 
to ensure that components from different vendors will work together. 

Supporting GOSIP does not mean that all systems are the same. Rather, 
OSI is broad enough, and GOSIP is loose enough, to allow considerable vari- 
ance. In particular, GOSIP only says that an environment must present a 
certain service (such as FTAM file access protocols) to the outside world. 
GOSIP requires that a collection of equipment must have a single access 
point that provides the specified OSI services, providing a link to other GO- 
SIP networks. Inside a particular collection of equipment, any protocols 
can be used. Instead of FTAM, for example, the network might use some 
internal protocol better suited to the needs of this particular collection of 
equipment, such as a distributed file system. FTAM and the internal proto- 
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col coexist; FTAM is used to talk to the outside world and the internal proto- 
col is used for local communication. 

This is exactly what DECnet/OSI Phase V does. DECnet/OSI Phase V is a 
collection of many services: Phase IV compatible services, new proprietary 
Phase V services, a few TCP/IP services, and the OSI basics. In some cases, 
the services can work together. For file access, for example, a network 
could easily have five different protocols: FTAM from the OSI world; the 
Data Access Protocol (DAP) from Digital; the Network File System (NFS) 
from Sun; the File Transfer Protocol from TCP/IP; and the Distributed File 
System from Digital. 

Some of these protocols have gateways. DAP and FTP can be joined us- 
ing a gateway on Ultrix (Digital’s version of Unix), allowing a DAP user to 
access resources in the FTP world. DAP and FTAM can also be connected 
together, using the DAP-FTAM Gateway from Digital. 

The relationship of these different protocols is the subject of this book. 
This is an architecture book: it explains the design of the protocols and 
their place in the overall architecture. It discusses which protocols provide 
service to others and which ones provide complementary services. It dis- 
cusses how the pieces all fit together to provide a collection of services to 
the user. 

Just as OSI is too broad to be fully implemented, so is DECnet/OSI Phase 
V. Phase V is a philosophy, in great detail, of how a network is put to 
gether. Specific products may implement one or more of those pieces. 

This book presents a framework from which to examine products. When 
a vendor, Digital or otherwise, says it supports some specific service, say 
FTAM, the reader will be able to put that information into perspective. The 
reader will understand how the FTAM service relates to other file access 
mechanisms, how it uses the services of the underlying session layer, and 
what the protocol itself does. 

This book also includes topics that are not, by a strict definition, part of 
Phase V. The Local Area Transport (LAT) is a protocol that is used for termi- 
nal servers to communicate with hosts (among other things). Because LAT 
is a key service provider in a Digital network, one cannot really understand 
Phase V without understanding what this complementary architecture does. 
It also discusses network management, the Maintenance Operations Proto- 
col (MOP), and the Naming Service. These topics are pieces that help pro- 
vide perspective on how a Digital DECnet/OSI Phase V network operates. 

There are even a few topics that are not covered at all in this book. The X 
Windows System, MOTIF, and other aspects of the Graphical User Interface 
are not covered because it was felt that they deserved their own book. Net- 
work-based graphics uses the underlying services of the network, so this 
book starts where those services end. 
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Overview of This Book 


Chapter 2 begins with the bottom of the protocol stack—the data link and 
physical layers. The book then climbs up the protocol stack, looking at serv- 
ices that build on each of the lower layers. Before we begin the climb, 
however, we will provide a quick overview of DECnet/OSI. After all, a 
climb is much easier if we know what awaits us along the way. 

We begin with a caveat. DECnet/OSI, Phase V of DECnet, is a new offer- 
ing. This means many of its pieces are just becoming clear. Most impor- 
tant, there are pieces, as with any architecture, that have not been defined 
or that have been defined and will not be used. We therefore discuss DEC- 
net as the Digital architects have envisioned it, not as the engineers have 
implemented it. 

Digital has gone through five stages of the Digital Network Architecture 
(DNA is the architecture, DECnet is the implementation of that architec- 
ture). Phase I was two PDPs with a wire strung between them—not exactly 
a network by current standards! 


Phase IV 


Phase IV of DNA is a network centered on Ethernet work groups, strung 
together with either wide-area bridges or routers. The wide-area systems 
use Digital’s DDCMP data link protocols. Built on top of the data link are 
proprietary network, transport, and session layers. 

Built on top of the Digital session layer is a wide variety of applications. 
The two most often used applications are the Data Access Protocol (DAP) 
and the Command Terminal (CTERM) protocols. DAP is a service for access 
to remote data and provides a variety of record level operations such as 
searches by index keys. CTERM is used for remote interactive access. 
CTERM, also known as the “SET HOST” command, allows a remote termi- 
nal to appear as a local one to the host system, much as Telnet does in the 
TCP/IP world. 

Over the years, DAP and CTERM were supplemented by a wide variety of 
other services. Messaging, for example, was first done using the mail-11 
message-handling protocols, and lately Digital’s proprietary MAILbus. Vide- 
otex, remote consoles for network management, booting diskless nodes, dis- 
tributed bulletin boards, and a host of other services are available for 
DECnet nodes. 


Phase V 


To see what DECnet Phase V encompasses, we start at the bottom of the 
protocol stack. The subnetworks (layers 1, 2, and some of the network 
layer) in Phase IV included Ethernet, the IEEE 802.3 version of Ethernet, 
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and DDCMP for wide-area communications. In addition, Phase IV supports 
X.25 networks, but only with permanent virtual circuits. Finally, the IEEE 
token-passing bus is also supported for MAP/TOP networks. 

Phase V has dramatically increased the support for subnetwork technolo- 
gies. In addition to DDCMP, Digital has added the HDLC protocols. In ad- 
dition to IEEE 802.3, it has added the FDDI services for faster LANs. More 
important, Digital has added two proprietary services that allow public data 
networks to be incorporated into a Digital environment. First, the Modem 
Control protocol, a physical layer service, allows a modem service such as 
V.25 or the Hayes AT command set to be dynamically established by a 
higher layer. The higher layer, in this case the network layer, has a Dy- 
namically Established Datalink (DED) component. The DED service will set 
up a modem call, an X.25 switched circuit or any other dynamic link, on 
demand. It will then keep that circuit up for a period of time, determined 
by management, in case more traffic comes through. After a period of inac- 
tivity, it brings the circuit down. 

Thus, for data links, Digital supports HDLC, including dynamic X.25 or 
V.25 circuits. For LANs, Digital supports the IEEE Logical Link Control 
(LLC). LLC, in turn, makes it possible for DECnet to easily incorporate Eth- 
ernet, FDDI, and maybe Token-Ring. 


Network Layer 


At the network layer, there are two issues that need to be addressed. First 
is whether any two nodes will be able to read each other’s packets. ISO 
8473 defines a standard format for data and error packets that DECnet/OSI 
uses. 

The second issue is how nodes find out about each other. Networks are 
composed of end systems and intermediate systems. If two end nodes on 
the same network want to communicate, the question of finding each other 
is not too difficult. The difficult issue is when an intermediate system 
needs to be used to route packets between different subnetworks (or within 
a single very large subnetwork). The question of routing information is 
addressed at two levels. 

First, ISO defines an End System to Intermediate System (ES-IS) routing 
exchange protocol that allows end systems and intermediate systems shar- 
ing a common subnetwork to find each other. This is accomplished 
through End System (ES) and Intermediate System (IS) hello packets which 
are multicast on an ISO-defined address. DECnet/OSI uses this protocol, 
defined in ISO 9542. 

The more difficult question for routing information is dynamic exchange 
of routing information between different IS systems. ISO 9542 defines how 
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an ES tells an IS about its existence. Currently, there is no ISO protocol for 
IS systems to tell other IS systems about the end systems they can service. 

The Digital protocol for this information exchange is the link state packet 
IS-IS protocol, which forms the basis for the current ISO draft. Digital’s 
IS-IS enables two routers to exchange routing information dynamically. It 
does this through the exchange of link state packets. A link state packet, 
which contains information on all a node’s neighbors, is issued by each 
intermediate system and sent to every other intermediate system on the 
network. After the packets are flooded through the network, the collection 
of ISs have a common view of the state of the network—the link state data- 
base. 

In addition to the link state database, every IS also keeps two other kinds 
of information. First, it has static routing information entered by network 
management. Second, there is a database of adjacencies, compiled from the 
ISO 9542 hello packets that have come in. Given these three sources of 
information, the routing decision process is able to decide which of the 
adjacent neighbors would be able to move a packet for a given destination 
one hop closer to its destination. 

To simplify the routing decision, Digital segments networks into areas. 
Within an area, the routing decision is made on the individual node ad- 
dress and is known as level 1 routing. Outside an area, the routing decision 
is made solely on the area address, and is known as level 2 routing. 

If a packet is forwarded via level 2 routing, eventually it will reach the 
destination area. There, it is handed off to a level 1 router for delivery to 
the actual node. Segmentation of routing into a hierarchy permits large 
networks to be built. Level 1 routers exchange link state packets that give 
the location of all nodes within an area. Level 2 routers exchange link state 
packets that show the location of all areas. 

Area-based routing is one way that Digital networks can coexist with 
other OSI-compliant networks. The Digital view of the world is a series of 
networks, connected together by public networks. Within a network, dy- 
namic routing information is exchanged. Across network boundaries, rout- 
ing information is manual. 

Interoperability at the network layer is thus achieved in two ways. If a 
vendor has an ISO 8473 compliant end system, the node can easily become 
part of a DECnet area. If the node also meets the ISO 9542 ES-IS protocols, 
the system will automatically configure itself (using an IS hello message). 
An alternative to making another vendor’s equipment part of the DECnet 
routing domain is to keep the networks segmented and connect the inter- 
mediate systems together using a common subnetwork (i.e., X.25) and static 
routing information. 

At the transport layer, Digital has traditionally used the Network Services 
Protocol (NSP), a reliable transport mechanism similar to TCP or the ISO 
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TP4 protocols. In Phase V, Digital supports three of the TP classes: 0, 2, and 
4. TP4 is the primary transport protocol for Digital applications; TPO and 
TP2 are there simply for interconnection to primitive non-Digital systems. 


Upper Layers 


At this point, the DECnet is a pretty faithful OSI network, with a few addi- 
tional features for backward compatibility such as DDCMP, and a few sup- 
plemental features such as the Dynamically Established Datalink and Mo- 
dem Control services. 

At the Session Layer, Digital supports two different session layers. The 
OSI Session Layer service is supported for OSI application services. Digital 
application services use another session layer service, the Digital Session 
Control protocol. We actually have here three kinds of networks: pure OSI, 
DECnet Phase V, and DECnet Phase IV. The pure OSI network (i.e., FTAM 
between two hosts) would use OSI Session, TP4, and the relevant lower 
layer protocols. Communication between Phase IV and Phase V would use 
the NSP transport and two interconnected routing domains. The Phase V 
network would use the Digital Session Control, TP4, and the Digital Phase V 
routing protocols. 

The number of possible combinations of protocol stacks in such an envi- 
ronment is potentially quite large. To keep track of the path available to a 
given application, Digital uses a concept of towers. A tower is a series of 
addresses from the network layer on up. One tower might be Digital rout- 
ing, TP4, Digital Session Control, and DAP. Another tower might be the 
same, but with the NSP protocols substituted for TP4. Each node keeps a 
set of towers, showing the possible combinations of protocols to be used for 
communication. 

To communicate between two nodes and/or applications, the Digital ses- 
sion layer compares the tower sets and comes up with a common subset 
that can be used. If there is more than one possible set of towers in com- 
mon, it is up to the initiating node to decide which one is best. 

The use of towers is thus one aspect of the Digital Session Control service 
that is different from the generic OSI service. Another aspect is the integra- 
tion with the DNA Naming Service (DNS). DNS is a distributed, replicated 
naming service used by the Session Control layer to keep node names and 
application names and their corresponding tower sets (addresses). 

The integration of DNS allows the user and application to communicate 
across the network using a logical name. The Session Control layer will 
translate the name into a tower set, which will then be handed down to the 
appropriate transport layer for initiation of a virtual circuit. 

The name server is used in more than just the Session Control layer. It is 
also an integral part of the Distributed File Service, and will presumably 
form the foundation for any Digital X.500 offerings. 
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Towers and DNS are strictly for use within the DECnet Phase V domain. 
For interconnection to the outside world, Digital uses the OSI Session layer. 
Built on top of that, Digital has two major services: FTAM and X.400. 

Digital’s FTAM implementation is fairly robust. It supports the first three 
document types (unstructured text, sequential string, and unstructured bi- 
nary). Digital has implemented the recovery functional unit. In addition, it 
has an FTAM/DAP gateway, which allows DECnet nodes to access non-DEC- 
net FTAM systems. 

Digital implements X.400 as a gateway into its own proprietary message- 
handling system, MAILbus. Within a DECnet environment, the Message 
Router is the Message Transfer Agent of MAILbus. It moves messages be- 
tween user interfaces such as ALLIN-1 and gateways. Digital has imple 
mented gateways for Telex, IBM’s SNADS and PROFS, TCP/IP SMTP, and 
X.400. 

The gateway takes an incoming MAILbus message and, using Digital’s 
Distributed Directory product, translates the address. It also does any trans- 
lation of the message body (i.e., ASCII to EBCDIC for the IBM world). The 
message is then sent into the next message handling system. Digital does 
not really do X.400; it gateways into that environment, which is equivalent 
as far as the user is concerned (and is fully compliant with X.400 and GO- 
SIP standards). 


True OSI? 


Is DECnet/OSI OSI? At the lower layers, Digital is using OSI internally. 
The data link, network layer, and transport layer protocols are compliant 
with OSI, and Phase V applications will use those protocols. Other proto- 
cols, such as NSP, are provided for backwards compatibility, but the OSI 
services are the primary Phase V infrastructure. At the session layer, Digital 
diverges into two coexistent networks. Pure OSI is used for interconnection 
to the outside world; Digital protocols are used internally. 

The issue is one of philosophy. Is this a true OSI network if most of the 
application effort seems to be focused in a Digital proprietary stack? The 
Digital marketing position is that they are adding value and that as the OSI 
standards stabilize and mature, we can expect to see things shift over to the 
OSI side of the stack. 

As an example, consider name servers. Integration of logical naming into 
the network has an important implication for a wide variety of different 
services. Digital uses the name server in the Distributed File System, for 
example, as a way of providing transparent mounting of remote file sys- 
tems. 

Another area where Digital supplements OSI is network management. 
Both Digital and pure OSI network management are based on the CMIP 
protocols. Digital has supplemented these in two ways. First, Digital has 


10 Analyzing DECnet/OSI Phase V 





architected the agents and event loggers on an individual node. Different 
network modules are able to give events to an event logger, which then 
uses the CMIP Management Event Notification subset to send the events to 
a variety of event sinks on the network. Likewise, Digital architected the 
management agent on a node, so incoming management directives are dis- 
patched to the appropriate network modules. These supplemental architec- 
tures mean that each module is not forced to implement its own CMIP 
initiators and responders. 

The second area Digital has architected for network management is the 
management director. It has done this at two levels. First, there is a net- 
work command language (NCL) which specifies how a user can input a 
CMIP directive and how it is parsed into CMIP. NCL also specifies the way 
in which results are displayed back on the user’s terminal or console. 

NCL is a fairly primitive, command-line based management director. A 
more ambitious effort is Digital’s Enterprise Management Architecture 
(EMA) and the associated Management Control Center (DECmcc) product. 
EMA splits the function of the director up into three pieces: 


© access modules 
e function modules 
¢ presentation modules 


The access module is responsible for communicating with manageable enti- 
ties. A CMIP access module would be used for communicating with a DEC- 
net Phase V entity, whereas a bridge management access module would use 
a different protocol for managing bridges. In addition to bridges and CMIP, 
Digital will be supporting T1 multiplexors and the LAT (used for terminal 
servers). 

Presentation modules are responsible for communicating with user de- 
vices. Digital presentation modules include DECwindows and traditional 
line-oriented interpreters. Finally, there are function modules. The point 
of this architecture is that a function (such as initializing an entity) can be 
applied over a variety of different network protocols at the same time. It is 
the responsibility of each of the access modules to communicate with its 
entities. 
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Subnetworks 


In the tradition of networking books, this chapter begins with a discussion 
of physical wiring, synchronous protocols, and other issues in the domain 
of providing bandwidth: lots of bits available to higher-level network serv- 
ices. It will, however, quickly leave these issues behind and concentrate on 
the data link part of the network. 

The purpose of a data link is to move a packet of data between two 
nodes. Since a data link may have many nodes on it, we refer to this serv- 
ice as a subnetwork. A variety of subnetworks exists, each suited to a differ- 
ent kind of environment. Chapter 3 will discuss how the network layer 
brings all these subnetworks together to form an integrated, cohesive inter- 
network. This chapter, however, concerns itself with the details of the dif- 
ferent subnetworks used in a Phase V network. 

The basic service of all these technologies is to move a packet of data 
between any two nodes connected to the subnetwork. Although the data 
link and physical layers may be quite complex—as in the case of FDDI, for 
example—the service is delivery of a datagram between any two nodes. In 
this sense, we can view all subnetwork technologies as a cloud (see Fig. 2-1). 

Throughout this book, you will see a variety of users of the data link 
service. The major user in a DECnet is the Digital Network Architecture 
network layer. In addition to the network layer, however, we will see that 
the Local Area Transport (LAT) is a direct user for terminal server to host 
transfer and the Maintenance Operations Protocol (MOP) uses the data link 
directly for downline loading operating systems from a remote host. Sup- 
port protocols, such as the naming service, the time protocol, and remote 
procedure calls, are also direct users of the service. In addition, other net- 
work architectures, such as TCP/IP, may be simultaneously sharing a data 
link with all these other protocols. 

Networks used to consist solely of point-to-point data links meant to tie 
pairs of individual computers together. These point-to-point protocols were 
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2-1 
Basic Function of the 
Subnetwork 





often meant to operate in a wide-area environment—this was in the days 
when computers were expensive and each site had one computer. 

An example of these point-to-point protocols is IBM’s bisync. In the Digi- 
tal environment, early PDP and VAX systems used the Digital Data Commu- 
nications Message Protocol (DDCMP). DDCMP is still used to connect nodes 
in a wide-area environment. 

DDCMP was quickly supplanted in a local environment by the Ethernet 
protocols. Digital networks have become Ethernet centric: Most Digital 
computers come with built-in Ethernet adapters, and special-purpose sys- 
tems such as terminal servers and print servers are all designed to fit on 
the Ethernet. 

The picture of DDCMP for wide-area network (WAN) connections and 
Ethernet for LANs has been supplemented in Phase V with several other 
subnetworking protocols. FDDI has been added as a high-speed LAN back- 
bone. X.25, used for years in DEC networks, has been integrated more 
tightly and is used to establish dynamic wide-area links and for using pub- 
lic data communications networks as a path in the middle of a Digital net- 
work. Finally, the HDLC protocols are increasingly being used as a 
supplement to DDCMP for point-to-point wide-area environments. 

As we shall see, the use of HDLC as a native protocol for DECnet/OSI 
Phase V is an important transition for Digital. The HDLC protocols form 
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the basis for the protocols used in some important wide-area architectures 
such as the Integrated Services Digital Network (ISDN). By ensuring HDLC 
compatibility, Digital makes it easier to move to technologies such as ISDN 
as they mature. It should be noted that Digital controllers have long sup- 
ported HDLC protocols in packages such as the X.25 Packet Switch Interface 
(PSI) software. The difference between Phase IV and Phase V is that HDLC 
plays a more important role in Phase V. 

This chapter will look at one additional protocol, Digital’s modem con- 
nect module. This module resides at the physical layer and allows the net- 
work layer to activate a modem-based connection dynamically when it 
needs a link to a particular destination. 

Dynamic data link capability becomes increasingly important as diverse 
networks interconnect. Interconnected networks are often needed only pe- 
riodically, and dedicated lines between them would be prohibitively expen- 
sive. The modem control protocol at the physical layer, along with the 
dynamic data link modules in the network layer, allow bandwidth to be 
allocated as needed. 

Although this chapter focuses on the data link layer, it occasionally refers 
to the physical layer of the network, particularly in the case of the two LAN 
technologies—Ethernet and FDDI. We will see that because the subnetwork 
and network protocols are merging somewhat, there is a need to discuss the 
use of data link-level interconnections (bridges) versus physical layer (re 
peaters) and network layer (router) strategies. 


Ethernets 


Ethernet was originally developed at Xerox’s Palo Alto Research Center and 
was subsequently standardized by the IEEE as the 802.3 LAN protocols. 
This book uses Ethernet to refer to both the original Ethernet and the sub- 
sequent 802.3 standards. When it is necessary to distinguish between the 
two, the term 802.3 refers to the IEEE standard and Ethernet Version 2 
refers to the latest version of the original DEC/Xerox/Intel specification. 

The basic configuration of any Ethernet is a shared bus. At its simplest, 
the Ethernet is a single wire with many nodes attached to it. Any one node 
can send a packet to any other node. As we shall see, the logical picture of 
a single bus or wire is an oversimplification of most actual physical configu- 
rations. Devices called repeaters are used to connect many different seg- 
ments into a multisegment Ethernet. These multisegment Ethernets can in 
turn be connected by bridges into an extended Ethernet. The whole tangle 
of wire looks to the user like a logical bus whereby any node can send a 
packet to any other node. We will see that this is not quite true: The de- 
vices connecting the pieces of the extended Ethernet together, the bridges, 
can filter out traffic. 


16 Analyzing DECnet/OSI Phase V 


CSMA/CD Protocols 


The basic operation of the Ethernet uses a protocol that goes under the 
catchy name of CSMA/CD: Carrier Sense-Multiple Access/Collision Detect. 
Carrier Sense means all nodes sharing the logical bus can sense whether 
another node is transmitting. If another node is transmitting, the well-be- 
haved Ethernet node waits. Multiple Access means if the medium is not in 
use, any node can send without waiting for special permission. 

Since any two nodes can send, it is possible that two nodes listen, sense 
the medium is free, and simultaneously start sending the data. The result 
is a collision on the network: equivalent to people talking at once. Whereas 
two people may ignore the resulting collision, in an Ethernet both nodes 
detect the collision and stop sending. 

Both nodes then wait for a random period of time (different for each 
node), then again listen to the medium. If the medium is free, they can 
start sending. Although it is theoretically possible for nodes to keep collid- 
ing and nothing be sent, in reality this method of sharing a bus works quite 
well. A typical Ethernet has an average use of around 10-15 percent, which 
is sufficient for all nodes to send when they want to with very few colli- 
sions. 

Studies show that when the average use of the Ethernet starts to ap- 
proach 30-50 percent, the number of collisions begins to increase exponen- 
tially. If all of a network’s nodes are on a single Ethernet, high growth of 
network use can indeed saturate the subnetwork. 

Realistically, however, most networks use multiple Ethernets. Nodes that 
frequently communicate with other are put onto a single Ethernet. Then 
either a bridge or a router is used to connect the multiple work groups into 
a single, integrated, extended LAN. The backbone of this LAN can be an- 
other Ethernet or an FDDI subnetwork. 


Ethernet Packet Formats 


Figure 2-2 shows the basic format of an Ethernet version 2 packet. Both the 
source and destination addresses have a 48-bit unique ID. IDs are univer- 
sally administered and delegated to the manufacturers of Ethernet control- 
ler cards. Note that a 46-bit unique ID (after you take into account the flags) 
is equivalent to 70,254,592,000,000 unique addresses. 

The first 2 bits of the ID are used as flags, and are thus not used as part 
of the individual address. The first bit indicates whether the address is an 
individual or a group address. A group address is used to refer to many 
stations (i.e., all DNA Phase V routers). An address of all 1s is a broadcast, 
which is received by every node on an Ethernet. The use of broadcasts is 
being strongly discouraged by most network architects, the rationale being 
that not all nodes on the network need to work just because some subset of 
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2-2 
Ethernet 
Version 2 Format 


nodes needs to communicate. Instead, multicast addresses—a group ad- 
dress of more limited scope—are encouraged. 

The second bit of the ID indicates whether the address is locally or uni- 
versally administered. Universal addresses are guaranteed to be unique. It 
is possible, although not necessarily wise, to administer the address space 
locally by having the network manager assign addresses. The reason this 
approach is not considered optimal is that it easily leads to duplicate ad- 
dresses when previously disjoint address spaces are joined together. 

Following the source and destination addresses is the protocol type indi- 
cator. This indicator shows for which user of the Ethernet service this par- 
ticular packet is meant. The protocol type indicator is how, for example, 
DECnet and TCP/IP can both share the services of a single Ethernet. The 
Ethernet module will deliver each packet to the appropriate user based on 
the protocol type field. Note the comment in Figure 2-2, which says the 
protocol type cannot be a valid length—we shall shortly see that the 802.3 
format of Ethernet has a length indicator instead of a type field and this 
restriction allows us to distinguish the two variations of the packet format. 

The length indicator is an optional field that is not part of the Ethernet 
specification but is sometimes provided so upper-level protocols can deter- 
mine if padding has been added. If included, it is the third field in the 
Ethernet packet. The data field in an Ethernet packet must be between 46 
and 1500 bytes long. The minimum length requirement for an Ethernet 
packet ensures that it will remain on the medium long enough for nodes to 
detect a collision if one occurs. Short packets mean short collisions and 
thus are hard to discover. 

The data part of the packet is transparent to the Ethernet module of the 
network. It could contain any data. Typically, it contains data for a user, 
such as the network layer. Thos data, in turn, will consist of a header for 
the network layer followed by some data, which will be a header for the 
transport layer and some data, and so on. 


18 Analyzing DECnet/OSI Phase V 


ee cate ee ee eee a 


| Source Address 
[iter geh eres rain 


Destination SAP 


PDU Type 


| Protocol ID 


| 


| Frame Check 
| Sequence 






































Only if DSAP = 
SNAP 





2-3 
IEEE 802.3 
Frame Format 


The pad is used to increase the data field so it reaches the minimum 
length requirement for the Ethernet. Following the pad is the frame check 
sequence (FCS). The frame check sequence is calculated based on the data 
being transmitted and appended to the end of the packet. The destination 
node will recalculate the FCS and then compare it to the one received. Eth- 
ernet is typically an error-free medium (error rates are in the range of 10”), 
so the FCS does not fail often. 


IEEE LANs 


Some aspects of the Ethernet frame format are protocol dependent; the 
pad field is not needed in a token ring, for example. When the IEEE began 
standardizing LAN technology, it broke Ethernet up into two sublayers: 


* Logical Link Control (LLC) 
¢ Medium Access Control (MAC) 


The LLC is medium independent and applies to all standardized LAN 
technologies, including the token ring, token bus, CSMA/CD, and FDDI. 
Underneath the LLC sublayer and on top of the physical layer is the MAC 
sublayer. Each LAN technology has its own MAC format. Figure 2-3 shows 
the packet format for an IEEE 802.3 LAN packet. Notice that the preamble, 
destination, and source addresses are the same as the Ethernet version 2. 
This is the MAC portion of the field. 

After the address fields is a length field. Because the protocol type field 
in Ethernet was required to be a number that is not a valid length, a node 
receiving a packet is able to determine which type of Ethernet packet it is 
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and can thus interpret the fields that follow. Ethernet protocol types are 
greater than the maximum packet length. 

Following the length field is a destination service access point (SAP) indi- 
cator. The destination SAP is the beginning of the LLC portion of the 
packet and would be the same for all MAC technologies. This field is some- 
what like the protocol type field in Ethernet version 2. 

There is a special SAP known as the subnetwork access point (SNAP). 
The SNAP is a placeholder that indicates that the real address of the user is 
in the first byte of the data field. If the SAP contains a real address, the first 
byte of the data contains user data. The source service access point is the 
address of the program on the sending node that submitted the frame. 

Finally, the LLC part of the header contains a protocol data unit (PDU) 
type field. There are two versions of the logical link control. In LLC Class 
I, the type used by Digital and most other vendors, the operation is connec- 
tionless—each packet is a stand-alone unit of information. 

In LLC Class II, which is connection oriented, it is up to the data link 
layer to ensure that all packets in a stream of data are delivered to the 
destination SAP in the order they are sent. LLC Class II thus performs error 
detection and recovery. 

LLC Class I is a best-effort delivery service. The packets are delivered, 
but there is no guarantee a particular packet will make it or that two pack- 
ets will be delivered in the order they are sent. 

Within the LLC Class I operation, there are three types of packets: 


® Unnumbered Information 
¢ Exchange ID 
° Test 


Frames sent by upper-layer service users are almost always Unnumbered 
Information (UI). The exchange ID (XID) and test frames are used for in- 
itialization and maintenance operations. 

Figures 2-4 and 2-5 show some typical Ethernet traffic as recorded on 
Network General’s Sniffer Analyzer. The Sniffer decodes each of the frames 
to show the headers of the different layers of a packet. In Figure 2-4 we see 
that the data link layer of the packet is Ethernet version 2. There is a desti- 
nation address, which is a multicast address to all Digital routers. There is 
an individual source for the frame, followed by the protocol ID, which is 
the general DECnet identifier. 

Following the data link portion of the packet is the data field. The data 
field is transparent to the Ethernet layer but does have some meaning for 
the routing layer. This particular packet is an Ethernet Router Hello Mes- 
sage. As far as the data link layer is concerned, however, the data field is 
transparent. 
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2-4 An Ethernet Frame 


Delta T——DST——————SRC 

@.6827 DECnet@@ZD1C+DECnet@@34iC DLC Ethertype=6803, size=68 byte 
DRP DATA D=7.45 S=7.5 
NSP CTRL Disconn Confirm D=@C3A 

8.7733 DECnet@@341C+DECnet@@ZD1C DLC Ethertype=6883, size=73 byte 
DRP DATA D=7.5Z S=7.4 
NSP CTRL Connect Initiate D=800@ 
SCP CONN D=17 (FAL) S=CAL 

@.1637 DEC Rem Cons+DECnet@83Z1C DLC Ethertype=686Z, size=68 byte 
MOP RC System ID Receipt=@ 


————- Session Control Protocol 


Destination Name: 

Name Format Type 8 

Ob ject Type 17 (File Access FAL’DAP-Version 4 and later) 
Source Name: 

Name Format Type Zz 

Ob ject Type @ (General Task, User Process) 

Group Code = 0368 
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2-5 Typical Ethernet-Based Traffic 


Courtesy of Network General 


Courtesy of Network General 


Subnetworks 21 
a ceo peeceeepenooeeeeeeeoereeneeneg~ oreeseo nn 


Figure 2-5 shows both detailed and summary views of traffic on the Eth- 
ernet. Again, we see that the packets are Ethernet version 2 (the indication 
of an Ethertype means that it is not an 802.3 packet). The first two packets 
bear the general DECnet protocol ID. The third packet is a specialized pro- 
tocol, the Maintenance Operation Protocol. 

In the first two packets, the concept of an envelope in an envelope is 
illustrated. The data link layer has a data field, which is actually a routing 
layer header plus data. Those data, in turn, are the Network Services Proto- 
col (NSP) or transport layer. Finally, the last envelope contains a session 
control protocol header plus data. In this case, the session layer packet is 
requesting that a connection be initiated, to exchange data using the appli- 
cation-layer Data Access Protocol. 

Again, at this point, we do not really care what is inside these packets. 
The function of the data link layer is simply to deliver a packet of informa- 
tion from one node to another. How that information is interpreted is the 
subject of the rest of the book. 

Figure 2-6 shows different addresses used in Digital networks. The first 
section of the figure shows a variety of LAN multicast addresses used in 
both types of Ethernets. The 48 bits of the address field is split into 12 
fields of 4 bits each. Each of the 4 bits is then given a number using the 
hexadecimal numbering system. All Fs, for example, are equivalent to all 1s 
in the address field. The last three parts of the figure show protocol types 
for Ethernet version 2, and the SAP and Protocol ID codes for use in the 
802.3 variant of Ethernet. 


Basic Ethernet Configuration 


Figure 2-7 shows the basic Ethernet configuration. Originally, this consisted 
of a piece of coaxial cable, also known as ThickWire or Baseband. Since 
then, a variety of physical media has been approved by the IEEE. These 
include: 


° 10BASE5 (ThickWire), standard coaxial cable. A single segment can be 
up to 500 meters long with 100 nodes. 

¢ 10BASE2 (ThinWire), a thinner coaxial cable with a smaller maximum 
length, but less expensive and easier to handle. 

¢ 10BASET which uses unshielded twisted pair. 

¢ Fiber used for security applications. 


Fiber is coming into broader and broader use. As an Ethernet segment, 
fiber is often selected because it is hard to tap unobtrusively. Fiber is also 
used for connecting repeaters and bridges, and as the basis for the high- 
speed FDDI LANs. 

The details of configuring the specific media are beyond the scope of this 
book. The typical configuration, however, consists of several components: 
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2-7 
A Bus Topology 





¢ the medium 

* a controller in the workstation, server, or any other device on the net- 
work 

¢ a transceiver used to attach to the medium 

* a transceiver cable used to connect the transceiver to the controller 


In many implementations, a multiport transceiver is used to connect sev- 
eral computers to the medium at one point of attachment. The multiport 
transceiver can be thought of as a concentrator. The Digital version of this 
device is known as a DELNI. 
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The controller in the workstation varies according to the type of periph- 
eral bus (and hence type of computer), as well as sustained throughput rate. 
Controllers also vary based on the type of physical wiring they support. 
Most controllers that support ThinWire also support unshielded twisted 
pair (UTP) through the use of a device called a balun (balanced/unbal- 
anced), which couples the ThinWire to the twisted pair. 
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In addition to standard computers, there is a wide variety of specialized 
devices that act as servers on the Ethernet. Figure 2-8 lists a variety of these 
devices from DEC—an up-to-date list can be found in Digital’s current Tele- 
communications and Networks Buyers Guide. As with Ethernet controllers 
and media devices, servers are available from a wide variety of vendors in 
addition to Digital 

Print servers and terminal servers are two of the basic specialized servers 
that reside on the Ethernet. The terminal server is an inexpensive way of 
putting many terminals in contact with different hosts on the network. In 
addition to terminals, the terminal server can connect modems and print- 
ers. The terminal server is covered in more detail in Chapter 7 on Local 
Area Transport protocols. 

Routers, covered in Chapter 3, are an alternative to MAC-layer bridges as 
a way of connecting several Ethernets together. The routers vary based on 
the number of connections they can support and the amount of throughput 
they have. As with other devices, routers are available from a wide variety 
of vendors. 


Multisegment Ethernets 


A single segment of Ethernet is typically limited to 30-100 nodes: the limits 
are based on the type of physical wiring used as well as the error rates and 
availability desired. The Ethernet architecture supports up to 1024 nodes 
on a single subnetwork. The way this is done is by connecting multiple 
segments using repeaters. 

Figure 2-9 shows a multisegment Ethernet connected together using re- 
peaters. The function of the repeater is to take all signals on one side of the 
repeater and retime, reamplify, and retransmit them on the other segment. 
The repeater thus logically extends the wire at the physical layer of the 
network. 

The basic rule of configuration for Digital Ethernets is that there can be 
at most two repeaters in the path between any two nodes on the network. 
This means a typical multisegment Ethernet consists of a backbone, with 
segments running off of it. Nodes on two different segments would go 
through two repeaters when sending packets of data to each other. 

The two-repeater rule is a means of ensuring that a collision will be de- 
tected within the architecturally defined parameters of the Ethernet proto- 
col. Every device, including transceivers, repeaters, and the medium itself, 
introduces delay into the network. 

In general, such rules are ways of making sure there is no excessive delay 
and that the Ethernet will work properly. Many different rules are used, 
depending on the type of medium and the vendor promulgating the rule. 
In the case of DEC, the methodology for wiring the Ethernet has been codi- 
fied in DECconnect, which includes the two-repeater rule. It is important to 
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note that this is just one of many available methodologies, all trying to do 
the same thing—provide a workable wiring for the Ethernet protocols. 
Several different repeaters are available. The typical repeater connects 
two ThickWire connections together using two transceiver cables. Other re- 
peaters, such as the Digital multiport repeater, connect one piece of Thick- 
Wire (the backbone) to up to eight segments of ThinWire or unshielded 
twisted pair. A third type of repeater is the fiber repeater, which enables 
the segments being connected together to be up to 1000 meters apart. The 
fiber repeater is actually two half-repeaters, each connected to one of the 
segments. The fiber is then connected to each of the half-repeaters. 


Bridging Ethernets 


The bridge is a device that transparently connects multiple subnetworks 
into an extended subnetwork. Typically, this means connecting two sepa- 
rate Ethernets into an extended Ethernet. The user of the subnetwork still 
sees the basic property of being able to send a packet of data transparently 
to any node on the subnetwork. - 

The difference between a bridge and a repeater is that the bridge only 
forwards those packets that need to be forwarded, whereas the repeater, 
operating at the physical level, retransmits every modulation of the signal. 

The bridge is thus a filter, selectively sending packets of data based on 
the source and destination addresses. To do the forwarding, the bridge 
must learn which nodes are on which side (see Fig. 2-10). When a bridge 
initializes, it starts listening to each port, noting which source addresses it 
sees on each side. Based on this information, the bridge knows the location 
of some nodes. The bridge will not know about every node, however, be- 
cause not all nodes will transmit information during the initialization pe 
riod. 

When the bridge sees a packet that has both destination and source ad- 
dresses on the same side, it has no need to forward the packet and ignores 
it. If the bridge notices that a destination address is located on the other 
side of the bridge from the source address, the bridge forwards the packet. 
When a bridge sees an unknown destination address, however, it always 
“floods” the packet; that is, it sends the packet out of every port it has (this 
model assumes the bridge has multiple ports, although the typical Ethernet 
bridge only has two ports). 

After a while, the destination of the flooded packet will send a response. 
The original destination node becomes the source address on the response 
packet. This information allows the bridge to update its forwarding tables 
to contain the location of the target node. 

Examination of the source portion of the Ethernet packet lets the bridge 
learn the location of nodes. The model assumes that a node is always on 
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2-10 Bridge Learning Algorithm 


one side or the other of a bridge. If there are loops in the bridge topology, 
however, then this model fails. 

To ensure there are no loops, bridges use a spanning tree algorithm 
which prevents the topology formed by the bridges from containing any 
routes that form a loop. If two bridges would form a loop, one of the 
bridges is disabled. Some bridges, such as the ones from DEC, can put 
themselves in a “hot” backup state, thereby taking over if the active bridge 
fails. A few vendors still sell bridges that do not use the spanning tree 
algorithm; these bridges must thus be manually configured to avoid loops. 

It is possible for several bridges to be in the path between two nodes (see 
Fig. 2-11). It is possible, in fact, to have the entire internetwork constructed 
using bridges. As long as there are no loops, the bridges will continue to 
forward packets and the entire extended Ethernet will look like one large 
subnetwork to the user. The problem with this approach is the rather sim- 
plistic routing method used by the bridge. We will see that the network 
layer uses a more sophisticated method to keep track of multiple paths be- 
tween different nodes, adjusting packet routes based on the relative per- 
formance of different paths. 
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2-12 TransLAN Wide-Area Bridges 
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One type of bridge shown in Figure 2-11 is the wide-area bridge. Digital 
remarkets the Vitalink TransLAN wide-area bridge as a way of connecting 
Ethernets together. Figure 2-12 shows the characteristics of a few wide-area 
bridges made by Vitalink. Notice that the TransLAN III and the TransLAN 
550 support up to eight wide-area connections to a single Ethernet. The 
bandwidth is up to 2.048 Mbps. This is one-fifth of the 10 Mbps speed on a 
single Ethernet. Typically, this will be more than enough bandwidth be- 
cause only a small fraction of the packets on one Ethernet will need to be 
forwarded to another Ethernet. If there is enough bandwidth, then the lim- 
iting factor for time-sensitive protocols (e.g., LAT) is the latency over the 
wide-area link. 

Many bridges include a filtering capability that allows only certain types 
of frames to be forwarded. DEC, in its internal network, uses wide-area 
bridges strictly for forwarding LAT traffic. Other traffic (such as DECnet) is 
filtered out. If a DECnet node wishes to communicate in a wide-area envi- 
ronment, that traffic is forwarded using a network-layer router. 

In addition to filtering by protocol type, many environments will choose 
to filter out broadcasts by setting the filter function on a MAC-layer bridge. 
Broadcasts may require an answer from every node. In a multisegment 
Ethernet, this might involve a few hundred nodes. In an extended Ether- 
net, this might involve several thousand nodes. If the broadcast results in 
all nodes broadcasting their answers, a storm of data can quickly incapaci- 
tate the network. 
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2-13 A Simple Ring 


FDDI and Token Ring 


Although the Ethernet operates at 10 Mbps, after the overhead of the data 
link layer and the collision avoidance mechanism, it is rare to see sustained 
throughput rates of more than 4-5 Mbps per second. Note that often this 
throughput is sufficient. A typical Ethernet will have 10-15 percent use and 
can easily support a network of 50-100 nodes doing diskless NFS and other 
fairly intensive protocols. 

There are times, especially with heavy use graphics or in an organiza- 
tional backbone, when the Ethernet is not enough. A faster network is the 
Fiber Distributed Data Interface (FDDI) which operates at a gross rate of 100 
Mbps; theoretically it can achieve throughput rates of 80 Mbps, and some 
studies have claimed throughput as high as 90 Mbps. 

The basic FDDI configuration is a ring (see Fig. 2-13). Each station on the 
ring copies incoming data to the next station. In addition to copying the 
data to the next node on the ring, a node may also make a copy of the data 
for its own buffers. 

FDDI controllers typically also include a bypass function, used when the 
station is not active (see Fig. 2-14). The bypass function allows the ring to 
keep operating despite the missing link. When a signal is bypassed at a 
node, it is not regenerated, and the signal attenuates. If too many consecu- 
tive stations are bypassing the signal instead of regenerating it, the signal 
will become too weak. 

The basic FDDI operation is similar to the IEEE 802.5 token ring, which 
operates at 4 or 16 Mbps. A difference is that FDDI usually consists of two 
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2-14 
FDDI Copy Operation 





rings. The primary ring is used during normal operation. If there is a 
break in the primary ring, the optional secondary ring is used to route data 
back the other way, providing a degree of fault tolerance. 

An FDDI configuration can have up to 1000 physical links on a total fiber 
path of 200 km. If dual rings are being used, this is equivalent to 500 nodes 
on a 100-km (dual) ring. There is a maximum inter-station distance of 2 
km. 

The FDDI ring circumference limit is based on a single architectural pa- 
rameter, the maximum ring latency, which is set at 1.617 ms. The maxi- 
mum ring latency is the time it takes for a starting delimiter to circulate the 
ring. From this parameter, the total number of nodes, the maximum dis- 
tance, and a variety of other ring parameters can be derived. 

As an example, assume we have a total path length of 200 km. At the 
speed of 5085 ns/km, 200 km of fiber introduces a latency of 1.017 ms. If 
there are 1000 physical connections, with a latency of 600 ns, this intro- 
duces a further latency of 0.6 ms. Thus, the total latency of a 200-km, 1000 
connection ring is 1.617 ms, equal to the maximum ring latency parameter. 
Changing the maximum ring latency parameter would change limits on the 
total number of nodes, the amount of fiber, or even the speed at which the 
network operates. 

Although it is possible to put nodes directly on an FDDI ring, many ven- 
dors use a multistation access unit (MAU) as a concentrator. The MAU is a 
station on the dual ring, connecting to both pieces of fiber. Coming out of 
the MAU are (typically) 8 or 16 ports. If a station is inoperative, there is no 
problem with the signal attenuating since the bypass function is provided 
at the MAU. 

One big advantage of the concentrator is that it is less expensive to pro- 
vide single-ring controllers for workstations and servers than it is to provide 
a dual-ring attachment. Figure 2-15 shows a possible configuration for a 
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2-15 FDDI Concentrators 


concentrator-based ring. Notice that a few stations are directly attached to 
the main ring. Most stations, however, are attached to the multistation ac- 
cess unit. 

The difference between directly attaching a station to the ring and using 
an MAU is one of philosophy. Digital has come down squarely on the side 
of using an MAU as an intermediate device, but other companies advocate 
direct attachment to the ring by a workstation. 

If FDDI is used as a backbone, then most stations are even further re- 
moved from the ring, being attached to an Ethernet. The Ethernet is con- 


34 Analyzing DECnet/OSI Phase V 















{ 






16 or More Idle 


| Preamble Suinbael 


} 
| Starting Delimiter 
| Frame Control Restricted Token? 


nected to the MAU using a bridge or a router. In the case of the Digital 
bridge, the device strips off the Ethernet header from the packet, puts on an 
FDDI header, and retransmits it. The bridge on the other side of the FDDI 
ring will perform the reverse operation, stripping the FDDI header and put- 
ting it back into Ethernet format. 

This translating bridge is in contrast to the encapsulating bridge, which 
merely adds an FDDI header on top of the Ethernet header. The encapsu- 
lating bridge only works if the data are destined for an Ethernet, whereas 
the translating bridge will work on a variety of MAC technologies. Since 
translating bridges are performing a sort of routing function, it might be 
simpler to dispense with the bridges altogether and use routers instead. 





2-16 
FDDI Token Format 


FDDI Operation 


In an Ethernet, any node can transmit if the medium is free. In a token 
ring such as FDDI, a node can only transmit when it receives a special 
packet, called the token (see Fig. 2-16). The token is passed from node to 
node on the ring. 

If a node has nothing to transmit, it just copies the token through. If it 
does have something to transmit, it captures the token. The capture proc- 
ess consists of failing to copy and retransmit the token and, instead, substi- 
tuting idle symbols where the token would have been. The node then has a 
set amount of time, governed by the token holding timer (THT), before it 
must replace the token on the ring. During that time, the node is free to 
send one or more data frames. A restricted token allows two (or more) 
nodes to engage in a dialogue by passing the token back and forth to each 
other without having to worry about other nodes cutting in. 

Once a data frame is sent, it will circulate through the ring. Presumably, 
at some point a node will see its address and copy the data into its buffers 
in addition to copying the data through to the next station. When the 
frame goes back to the sending node, it will strip the frame from the ring 
by replacing the data with idle symbols. 

Figure 2-17 shows the format of the data frame. At the end of the frame 
is the frame status field, which is used to see if a destination node recog- 
nized its address. If it did, it flipped the address recognized bit. If it also 
had enough room in its buffers to copy the frame, it flips the frame copied 
bit. The error detected bit is used if a frame check sequence fails. 
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The data field is theoretically limited to roughly 8000 bytes, although 
most users of the FDDI will have much smaller packet sizes. Inside this 
data field would be the LLC header, followed by the headers for upper lay- 
ers. 

The frame control field is used to govern the basic operation of the ring. 
The address length bit, for example, selects a 2-byte or the standard 6-byte 
address. The frame type indicates if this is an internal MAC-management 
frame, one used for the FDDI station management (SMT) function, or an 
LLC data frame. More information on the frame type, priority bits, and 
class bit is presented in the following sections. 


Frame Control 
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FDDI Frame Format 





Modes of Operation 
An FDDI ring operates in two modes: 


¢ Synchronous mode guarantees a certain amount of bandwidth and re- 
sponse time to nodes. 
¢ Asynchronous mode provides dynamic bandwidth sharing. 
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Asynchronous mode is instantaneously allocated via the token, whereas syn- 
chronous bandwidth is allocated ahead of time using SMT protocols. Note 
that initial FDDI implementations (including Digital’s) do not make use of 
synchronous mode. 

Synchronous bandwidth is allocated as a percentage of the target token 
rotation time (TTRT), which is another way of representing the total band- 
width on the network. The sum of the synchronous allocations should be 
less than or equal to 100 percent. 

Each node with a nonzero bandwidth is allowed to transmit data frames 
for a period of time, without having to worry about starting the token rota- 
tion timer. If, after all nodes complete their synchronous transmissions 
there is still some bandwidth available, nodes can do asynchronous trans- 
mission up to the limit of the token holding timer. 

Asynchronous transmission is a two-tier allocation of the bandwidth: 


* Nonrestricted mode provides time slicing among all nodes that wish to 
send data. 
° Restricted mode is dedicated to a single extended dialogue. 


The normal operation is nonrestricted mode. In this mode, allocation of 
the token is based on a priority scheme. The priority scheme is based on 
the amount of time it takes for the token to circulate the ring. Each priority 
level has a threshold token rotation time. 

As the token rotation time (TRT) gets longer and longer, the lower prior- 
ity levels are cut off. Nodes can then only send data of higher priorities. As 
the token goes around the ring with a high priority, eventually all nodes 
will have sent their high priority data. This means the token will go 
around the ring more quickly, allowing lower priority data frames to be 
transmitted. 

The target token rotation timer is the total bandwidth available on the 
ring. After the synchronous transmission is finished, there may still be a 
certain amount of remaining bandwidth, symbolized by the token rotation 
timer. The difference between the current TRT and the target TRT is thus 
the available asynchronous bandwidth—the minimum value of the TRT is 
equivalent to nobody sending synchronous traffic. 

When a nonrestricted token is received, restricted mode is entered by two 
nodes. The first node sends an initial batch of data, then issues a restricted 
token. The receiving node sends its data, then sends the restricted token 
back out. 

Restricted mode prevents all unrestricted asynchronous traffic (including 
basic station management tasks such as exchanging neighbor IDs). The de 
cision to enter, terminate, or continue a restricted dialogue is up to the 
higher layers using FDDI. Since synchronous transmission is unaffected by 
the token, it is unaffected by the restricted mode. 
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One of the functions of the station management is to negotiate a maxi- 
mum restricted mode time. Note that in restricted mode, there is really no 
need to obey the token holding timer—by its very nature restricted mode 
has already preempted fairness with other nodes. 

Restricted and synchronous modes are optional features in FDDI. Re 
stricted mode would presumably be used by critical functions such as sys- 
tem management. Synchronous mode would be used by time-critical 
applications such as voice. 


Ring Initialization and Recovery 


Any station that detects a need to initialize the ring issues a claim token 
frame. Multiple stations bid for the right to lead the initialization of the 
ring by continuously transmitting claim frames. Each station engaged in 
the bidding looks at an incoming claim frame to detect whether the frame 
is the one it originally sent or is another station’s bid. Each frame contains 
a bid value, and the highest bid wins. A node that lost the bid would start 
copying frames through. At some point, one node’s claim frame will circu- 
late all the way around the ring and arrive back at the sending node, signi- 
fying a successful bid. 

In the case of conflicting highest bids, arbitration is based on target token 
rotation time (TTRT), which is used to indicate how long a token should 
take to circulate the ring continuously. The lowest TTRT wins the bidding 
process. If there are multiple low TTRT values, then the highest station 
address wins. 

As soon as a station wins the claim token process, it begins the ring in- 
itialization process. First, it sets the target token rotation timer to the value 
in the successful claim frame. It then resets the token rotation timer (used 
to detect a token that has gone awry) and issues a nonrestricted token. 

This token will go through the ring three times before normal data traffic 
is possible. On the first round, each station sets the TRT value, then sets an 
internal flag to indicate that the ring is operational again. On the second 
round, synchronous traffic is issued. On the third round, asynchronous 
traffic can begin. 

The claim token process is timed by each station. If the timer expires 
and the bidding is still unresolved, a station whose timer expires will begin 
transmitting a beacon. Note that only stations that are still in the bidding 
process can send a beacon. If a station is out of bidding and its timer ex- 
pires, it reenters the bidding process. 

The purpose of the beacon frame is to pinpoint where in the ring a prob- 
lem is occurring. The beacon indicates that a significant logical break in 
the ring has occurred, either because a station is inoperative or because the 
medium has a break. 
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Each ring transmitting beacons will transmit them continuously. As in 
the case of the claim token, any incoming beacons are examined. If the 
station address on the incoming beacon is different, it means a station up- 
stream is also sending the beacon and downstream nodes will yield by ceas- 
ing to transmit their own beacons. 

As each node yields, the source of the beacon gets closer and closer to the 
break in the ring. At some point, when the ring is fixed, a node will see its 
own station address in a beacon. This means the ring is operational again, 
and the claim token process is entered. 


DDCMP 


The Digital Data Communications Message Protocol (DDCMP) is one of the 
earlier Digital protocols, initially used for communication between PDP 
computers. DDCMP is a data link protocol that supports a wide variety of 
physical media (see Fig. 2-18) as well as a variety of users. The typical user 
is the DNA routing layer, but it is also used by MOP modules for remote 
booting. There is also a variety of (typically old) user programs that make 
direct use of DDCMP for wide-area point-to-point communications. 

DDCMP is flexible, operating over a variety of lines including asynchro- 
nous and synchronous lines. DDCMP also supports serial, parallel, and 
multipoint lines. The type of physical connection supported is a function of 
which communication controller is being used, not the protocol. Figure 2- 
19 shows some typical communications controllers used on Digital comput- 
ers. Note that dedicated devices, such as routers, also have DDCMP-based 
connectors. Also note that the DDCMP controllers vary based on the num- 
ber of lines and the total bandwidth. 

Direct Memory Access (DMA) means the controller can deposit incoming 
data in memory instead of having to generate a CPU interrupt so the CPU 
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2-19 WAN Communications Controllers 


can perform the task. Non-DMA access is quite CPU intensive. For exam- 
ple, the DPV11 controller, with no DMA access and a bandwidth of 56 kbps, 
could easily swamp the resources of a MicroVAX. 

Modem ‘control means the controller is able to detect changes in modem 
signals and transmit that information up to higher-level users. This is im- 
portant when the line is going to be used by incoming terminal sessions 
(i.e., a DMB32 in asynchronous mode). 

As an example, suppose a user dials in and establishes a session. Then, 
for some reason the connection is broken. When a second user dials into 
that same port, he or she is automatically connected to the previous user’s 
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session. Modem control ensures that the higher-level user (the VMS operat- 
ing system) detects the break and terminates the session. 


DDCMP Operation 


The operation of DDCMP can be broken down into three functional com- 
ponents: 


° framing 
¢ link management 
° message exchange 


Framing is provided by DDCMP at three levels. The lowest level, bit syn- 
chronization, is actually done by the physical hardware, such as a modem. 
Byte synchronization is also part of the physical interface (except for asyn- 
chronous or parallel links, where the process is inherent). The highest level 
of synchronization is at the message level: finding the first and last bytes of 
the message. This is where the major work for DDCMP is accomplished. 

Link management is the process of switching between transmit and re- 
ceive modes. Message exchange is based on positive acknowledgment and 
timers. 

Several error detection and performance enhancement mechanisms are 
used in DDCMP. When a user sends data, a timer is set to ensure the data 
does not go into a black hole. It is the responsibility of the recipient to 
acknowledge the data. 

If an ACK is not received when the timer expires, a special Reply to Mes- 
sage Number (REP) message forces an ACK or NAK from a node. 

Positive acknowledgment of messages can be inefficient in an environ- 
ment with a long transmission delay (such as a satellite link). If a second 
packet cannot be sent until the first packet is acknowledged, the long delay 
will reduce throughput to a small fraction of the total bandwidth. DDCMP 
uses a mechanism called pipelining, which allows several messages to be 
outstanding. An ACK message acknowledges the receipt of all messages up 
to the one being specifically ACKed. The combination of pipelining and 
piggybacked ACKs means DDCMP is efficient for most realistic (i.e., nonin- 
terplanetary) situations. 

Note that many DDCMP functions can be implemented in hardware. 
Framing, CRC calculation, and interpretation of some message fields are all 
likely candidates for hardware implementations. 

DDCMP can operate on both asynchronous and synchronous links. For 
an asynchronous link, it is possible to lose the start of the byte. If so, the 
module sends a byte of all 1s, followed by an idle for at least 10 bit times. 
This lets the other end resynchronize itself. 

On a synchronous link, byte framing is established by looking for at least 
two consecutive sync bytes. When a module is sending a start of frame 
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2-20 
DDCMP Data Message 


sequence, it sends a total of six sync bytes; after the first two are detected, 
the remote node will look for another four consecutive synchronization 
bytes. 

Synchronization is not necessary between each frame. It is possible to 
send several messages abutting each other. If there is space, however, the 
link needs to be resynchronized. 

The remote node will typically buffer all incoming data under the as- 
sumption that consecutive frames will be transmitted. This means that a 
lot of useless data can be buffered before the remote node realizes there is 
no frame, just line noise. The quick sync flag in a frame tells the remote 
node that no frames will follow this one and that it should await a start of 
frame sequence. Once synchronization is achieved on the line, the message 
framing is accomplished by looking for the 3-byte beginning of message 
sequence. 

Before a line is properly initialized, DDCMP is running in off-line (main- 
tenance) mode. A start message, followed by a start acknowledgment, shifts 
the line to on-line (operational) mode. The start message is used to resync 
message numbers. 

The reply timer tells a module how long to wait for an acknowledgment 
before taking error recovery action. On a full-duplex line a typical value 
would be 3 seconds for a telephone-type, low-bandwidth channel. On a 
half-duplex line a selection interval indicates the amount of time the other 
node has to respond. 
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DDCMP Messages 


Figure 2-20 shows the basic DDCMP data message. Notice that the message 
includes a response number allowing acknowledgment of data to be piggy- 
backed on the outgoing data message. The transmit number indicates the 
number of this message, which should be positively acknowledged by the 
recipient. 

The station address is used in a multipoint link environment. In a multi- 
point link several nodes share a single line. One of the nodes is the master. 
Communication is between the master and one of the slaves; slave-to-slave 
communication is not possible. Multipoint DDCMP operation is not sup- 
ported in DECnet Phase V. 

The quick sync flag is used to indicate that the recipient node should 
resynchronize the line immediately following the message instead of trying 
to buffer the reverse data. The select flag is an artifact of multipoint opera- 
tion and indicates which node is allowed to transmit. 

The other two message types are the maintenance and control messages 
(see Figs. 2-21 and 2-22). The maintenance message is used when the link is 
not initialized for normal operation. A typical user of the maintenance 
message would be MOP. 

The control message is used if a node is forced to NAK a message or send 
an ACK, but has no normal data message on which to piggyback. The start 
and start acknowledgment (stack) messages are also subsets of the control 
message. 

Figure 2-23 shows a variety of management parameters kept by the DD- 
CMP module. All DNA modules keep management information. Some pa- 
rameters are control parameters, used to set the operation of the module. 
Other parameters are status parameters, which keep the current status (i.e., 
number of framing errors detected). 

The information in these figures gives you an idea of the scope of the 
information kept in all DNA modules. Since listing all the information kept 
by all the DNA modules would easily fill up pages of this book, a sample is 
shown for a single module. 


HDLC 


Whereas DDCMP is a Digital proprietary protocol, the High-Level Data Link 
Control (HDLC) is an international standard. There is therefore a wider 
variety of implementations available for HDLC-based products than for DD- 
CMP-based products. Digital is moving away from DDCMP toward HDLC as 
the method of providing point-to-point, synchronous wide-area communica- 
tions. DDCMP is still being used for low-cost asynchronous circuits. 

The basic HDLC goal is reliable, sequenced, transparent, error-free data 
delivery over communication links that have significant induced error 
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rates. HDLC provides both half- and full-duplex operation. It allows resyn- 
chronization of a line in case of temporary failures. 

HDLC uses the concept of bit stuffing to locate the beginning and end of 
messages on a physical link. Within HDLC there are flags, consisting of six 
consecutive 1s. If the data contained this combination, a message would be 
prematurely terminated. Whenever there are five consecutive 1s in the 
data, HDLC adds a 0. 

Normally, the gap between two HDLC frames is a sequence of 8 bits: a 0, 
a flag (six 1s), and a 0. When a second frame follows directly after the first, 
the line may lose the second frame: It may still be processing the CRC, 
doing the DMA posting, or checking the address and be unable to copy the 
incoming data to a buffer. For nodes with limited processing power, it is 
therefore possible to negotiate a minimum acceptable interframe gap con- 
sisting of additional flag sequences. 

HDLC is a general-purpose protocol. As such it is too general for general- 
purpose automatic configuration. When Digital supports HDLC, they are 
therefore supporting a limited subset of HDLC devices. Digital’s support of 
HDLC does not include support for multidrop (which is basically limited to 
SDLC-based secondary stations) or asynchronous operation. 

Within the general HDLC framework, there is a variety of important sub- 
sets, including 


* the synchronous data link control (SDLC) used as the basic data link 
mechanism in IBM SNA networks 

¢ the link access protocol B (LAPB) used in X.25 

¢ the link access protocol D (LAPD) used in ISDN 


Digital supports the two basic modes: normal (half-duplex) and balanced 
(full-duplex). LAPB is a particular variant of balanced mode. LAPX and 
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LAPD, as well as the now obsolete asynchronous mode are not supported in 
the current specification. 

A variant on normal and balanced mode is extended format. Extended 
format allows 7-bit sequence numbers instead of 3 bits, thereby allowing 
more frames to be outstanding. Extended format is needed for efficient 
operation over long-delay links such as satellite-based transmission. 

HDLC, like DDMCP and most other synchronous protocols, is based on 
pipelining. Each message gets a sequence number. When an acknow- 
ledgment is received, it implies receipt of all previous messages (in other 
words, the acknowledgment sequence number is the next frame expected). 


HDLC Frame Structure 


Figure 2-24 shows the basic format for the HDLC frame header, known as 
the control fields. The first 2 bytes of the frame (3 in extended) define the 
frame type. There are three types used in HDLC: 


¢ The information (I) frame is for user information. It is subject to error 
recovery and sequence control. 

° The supervisory (S) frame is for control information such as acknow- 
ledgments, retransmission request, and temporary busy indications. It 
is used to ensure the correct transfer of I frames. 

¢ The unnumbered (U) frames provide link control functions such as in- 
itialization and termination, as well as unacknowledged user data. 


Each of these frames can be a command or a response. In a half-duplex 
mode, one node is the master, the other the secondary. Only the master 
sends commands; the secondary only sends responses. In balanced mode, 
either can send commands or responses. To determine which type of 
frame it is, we look at the station address field. If the sender’s address is in 
the field, it is a command. If the receiver’s address is in the field, it is a 
response. 

Each frame has a poll/final bit. In commands, the bit is a poll bit. In 
responses, it is a final bit. In normal mode (half-duplex) the poll bit set 
indicates that the slave can send data; this is the beginning of a transmit 
opportunity. The slave then sends data until it is done, at which point it 
sets the final bit. The poll/final bit is thus a way of synchronizing two 
stations. 

Error detection is done using either a 16- or 32-bit CRC. Digital always 
begins the initialization procedure using the 16-bit CRC but switches to the 
32 bit in data transfer phase if it is negotiated. 
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Error Recovery 


The basic method for error recovery is checkpointing. When an acknow- 
ledgment is received with the final bit sent, it indicates a checkpoint. The 
checkpoint means that all lower-numbered frames have been received but 
no higher-numbered frames have been received. In other words, the other 
node should resend any outstanding higher-numbered frames. 

The checkpoint procedure is usually started after the acknowledgment 
timer expires. By setting the final bit on the acknowledgment, we are indi- 
cating to the remote node that we have not received any higher-numbered 
frames. 

Other ways to recover from an error occurs when the node receives an 
out of sequence frame. Sending a reject forces retransmission. On long-de- 
lay links (satellites) there is a refinement to HDLC called selective rejection; 
this is not specified in the Digital HDLC document. 


Link Initialization 

Link initialization goes through three phases. First, there is attempt to ex- 
change XID frames. If there is response before a timer expires, we assume 
the remote node does not support the XID. Next, a disconnect indication is 
sent to force a disconnected frame. Then, the link is established in normal, 
balanced, or extended mode. 

Flow control is done through the use of the Receive Not Ready (RNR) 
frame instead of a receive ready. The other station will then test peri- 
odically to see if the condition still exists. 

HDLC normally assumes two direct users of the line. There is no inher- 
ent provision for multiplexing multiple users over a single link. Digital pro- 
vides this service, but only with the use of unnumbered information 
frames, by putting a protocol ID as the first piece of the data field. To 
suppress the use of protocol IDs in UI frames when communicating to non- 
Digital nodes, Digital allows a link to be started in exclusive mode. 

For sequenced information, there can be only one user. Note that this is 
not the end user—a single user might be the Digital routing protocol. 


X.25 


At the data link layer, the X.25 protocols are a subset of HDLC. In addition, 
X.25 defines functions at the physical and the network layer (see Figs. 2-25 
and 2-26). The network layer function of X.25 is used to set up a virtual 
connection between two nodes in the X.25 subnetwork. Then the LAPB pro- 
tocols define how a user of X.25 interfaces to the network. X.25 is actually 
used in a wide variety of different portions of the Digital network. 
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X.25 is connection oriented. The user at the network layer sets up a vir- 
tual circuit:to a remote destination. The virtual circuit can stay perma- 
nently in place or can be set up dynamically (a switched virtual circuit). 

Figure 2-27 shows a typical X.25 configuration. Notice that X.25 only 
specifies the interface to the network; the inner workings are implementa- 
tion dependent and are thus represented as a cloud. 

X.25 can be used for a wide variety of purposes. For host-to-host commu- 
nication, a higher-level program is resident on both computers. Thus, the 
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2-27 An X.25 Configuration 


router on the Ethernet might set up a virtual circuit to a minicomputer or 
mainframe or even to another router. In Chapter 3, we will see that X.25 
can be used as a means of connecting multiple LANs together. 

X.25 is also a means for a terminal to communicate with a host. The X.25 
protocols define synchronous data transmission, but terminals are usually 
asynchronous. A device known as a packet assembler/disassembler (PAD) is 
used to interface the asynchronous device to the synchronous X.25 network. 
The operation of the PAD is defined in the X.3 CCITT standard. 

Two additional protocols are used to define how the terminal (or the 
workstation emulating a terminal) and the host communicate with each 
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other. The X.28 protocols define how the terminal interfaces to the PAD. 
X.28 defines evenents such as when the PAD should take data received and 
bundle it up in an X.25 packet. The X.29 protocols define how the host can 
communicate with the PAD and thus control the terminal. 

In a Digital environment, it is possible to make a VAX computer emulate 
an X.3 PAD using Digital’s Packet Switch Interface (PSI) software. By emu- 
lating a PAD, the PSI software lets users initiate outgoing sessions to hosts. 
In addition, PSI is able to accept incoming sessions. PSI does not require 
DECnet for local users, although DECnet allows users to access the services 
of a remote X.25 gateway. 

PSI allows direct use of the X.25 network by users or user programs. A 
special instance of a user is the Phase V network layer. When X.25 is a 
service provider for the network layer of a Phase V environment, an X.25 
router—a dedicated piece of equipment that interfaces to the Ethernet and 
to the X.25 network—is used. The X.25 router is the same basic hardware 
used in DDCMP-based routers with point-to-point connections. 

Another variant of X.25 in a Digital environment is the X.25 portal. The 
X.25 portal allows a DECnet to be used as a backbone for foreign traffic. 
The X.25 portal accepts incoming’ messages and encapsulates them inside a 
DECnet packet. The packet is then sent to a portal on the other side of the 
network, where the DECnet header is stripped and the data packet is sent 
back on its way. 

X.25 is particularly important in Phase V because the intent of the archi- 
tecture is to interconnect to other networks easily. Since OSI defines a uni- 
fied address space, it is technically possible for a network to establish an 
X.25 call dynamically to a remote network for the purpose of, say, exchang- 
ing mail messages. 

Most sites would typically pick one X.25 vendor. In the United States this 
would be Tymnet, Telenet, or one of the other public service providers. In 
many other countries, the X.25 service provider would be the local PTT. 

Once connected to one X.25 network, it is still possible to reach a destina- 
tion target on another X.25 network. The X.75 protocols define how one 
X.25 network interconnects to another. A switched virtual circuit could 
thus be established across national boundaries. 


Modem Connect Module 


Before leaving the data link layer and subnetworks, we will look at one 
more module, the modem connect module. This module is part of the 
physical layer of the network and allows the control of modems. Figure 
2-28 shows an HDLC module that connects to a wide-area link via a modem. 
DDCMP can also use the services of this module. 
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Once the operation is set’ up, the HDLC module uses the normal data 
transmission facility of the physical layer. To set up a call, however, re- 
quires capabilities not present in the HDLC protocols. This is where the 
modem connect module comes in. 

Figure 2-29 shows a more detailed view of the modem connect module. 
The dynamically established data link component of the DNA routing layer 
is responsible for interfacing to the call control service interface. This inter- 
face, in turn, is able to work with a variety of different modem control 
protocols to establish a connection to a remote location. 

Once the connection is established, the network layer (or other user of 
the data link layer) sends its request for transmission to the data link layer 
module, which then interfaces to the physical layer of the network. The 
call control service interface is thus a mechanism used before the link is up 
and running and is thus not really a network protocol. 


Summary 


In this chapter, we looked at a variety of different protocols for setting up a 
subnetwork: a means of connecting multiple nodes together so any two 
nodes can exchange a packet of data. In the next chapter, we will see how 
the network layer joins these various subnetworks together into an inte- 
grated network. 

For the local area network, the Ethernet CSMA/CD protocols are key for 
Digital. Most servers, such as computers, terminal servers, and print serv- 
ers, come with built-in Ethernet interfaces. The Digital view of the world is 
a series of work groups, connected together with Ethernet. 

In addition to Ethernet, Digital supports the FDDI local area network, 
primarily as a means of providing a high-speed corporate backbone. 
Bridges or routers then connect the FDDI to the Ethernet-based work group. 

For wide-area connections, Digital originally supported the DDCMP proto- 
cols. DDCMP will be used in Phase V for asynchronous connections, as well 
as for synchronous connections to provide backward compatibility. 

In the wide-area environment, Digital is moving toward HDLC-based con- 
nections. HDLC is used for point-to-point connections, and is also the basis 
for interconnection to X.25 and ISDN. 

X.25 (and later ISDN) plays a key role as the interface to the public data 
communications environment. X.25 allows a switched virtual circuit to be 
dynamically established, allowing short-term connections to be easily estab- 
lished to a wide variety of different targets. 

The last thing we looked at was the modem connect module which, with 
X.25, presents a choice of ways to provide dynamic wide-area links. X.25 
uses the public data network, whereas the modem connect module allows 
point-to-point links to be established over the public voice network. 
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Network Layer 


The data link layer provides a basic service—transmission of a packet of 
data between any two nodes on the subnetwork. The DNA architecture al- 
lows a variety of different data link technologies, and a node may actually 
be connected to several different subnetworks. 

The function of the network layer is to tie the different subnetworks to- 
gether (see Fig. 3-1). In this sample configuration, several kinds of subnet- 
works are being used, each suited to the particular task at hand. FDDI acts 
as a high-speed backbone, Ethernet is used for work group computing, and 
HDLC, DDCMP, and X.25 are used for wide-area links. This is just one kind 
of possible configuration. FDDI, for example, might also be used for work 
group computing, as in the case of visualization workstations connected to 
supercomputers. 

The basic role of the network layer is to deliver a packet of data from any 
one node in the network to any other node. The network layer uses the 
services of the data link to move the packet across a subnetwork, then 
chooses another subnetwork to move the packet one step closer to its desti- 
nation. 

The problem is knowing which subnetwork to use to move the packet 
one step forward. With all the nodes on one subnetwork, it is simply a 
matter of submitting the packet to the data link layer. In a multisubnet- 
work environment, just knowing which nodes exist is a challenge. A fur- 
ther wrinkle is introduced by multiple paths between any two nodes. 
Keeping abreast of which nodes exist and the best way to get there is the 
function of the network layer. 

The network layer is a user of the different data link services (see Fig. 
3-2). In DECnet, the network layer provides a best-effort delivery service: It 
tries to move a packet across the network. 

The user of the network service will be the transport layers of the net- 
work. The transport layer, examined in Chapter 4, makes sure that all pack- 
ets submitted by a given user are received at the destination node in the 
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3-3 End Systems and Intermediate Systems 


order sent. Using the network layer, the transport layer can be unaware of 
the topology of the network—the combination of data links that provides a 
path between two nodes at a given point in time. 

We can divide the universe of all nodes that have some form of connec- 
tion (or potential connection) into three categories: 


e Phase V nodes 
e Phase IV nodes 
® non-DNA nodes 


Based on their function we can further divide each of these types of nodes 
into end systems and intermediate systems (see Fig. 3-3). The correspond- 
ing terms for Phase IV networks were end nodes and routing nodes. An 
end system is able to send and receive traffic on the network but does not 
route traffic through on behalf of other nodes. A typical end system is a 
multipurpose server or workstation, but specialized end systems could be 
terminal servers, print servers, or any other device implementing the net- 
work layer functions. 

An intermediate system performs a forwarding function on behalf of 
other nodes. An intermediate system can also be an end system, originat- 
ing traffic on behalf of itself. It does not have to be a traditional host, such 
as a VAX. Often, intermediate systems are dedicated hardware and soft- 
ware packaged as a router. In fact, as routing functions become more com- 
plex it becomes increasingly important to off-load these functions from 
general-purpose hosts onto specialized routers. 

In most networks, there may be several paths to the destination, each 
path represented by a different neighboring intermediate system. Which 
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intermediate system to use to move a particular packet of data closer to its 
destination is the crucial decision in the network layer. A given node may 
be connected to several different subnetworks. Each subnetwork may have 
several different intermediate systems connected to it, which in turn are 
connected to other subnetworks. The number of possible paths to a given 
destination can thus be very large. 

We can examine the network layer from three increasing layers of com- 
plexity. At the lowest level of complexity, we assume a simple network 
topography (or at least a node that has very little knowledge of the topogra- 
phy). Our only concern at this point is to standardize the format of the 
data packet. This is addressed by the basic ISO standard for the network 
layer. At this level, we assume that an intermediate system already knows, 
through some out-of-band mechanism, how to find a destination end sys- 
tem. 

The next level of complexity is the mechanism by which a node finds its 
neighbors: determining the presence of neighboring intermediate systems 
and end systems. This is the function of the ISO ES-IS Routing Exchange 
Protocol. By sending out “hello” messages, all nodes on a subnetwork in- 
form their neighbors of their presence. 

Finally, at its most complex, we have the IS-IS protocol, which is in- 
tended to allow an intermediate system to determine the best path to any 
node in the network, whether it be a neighbor or not. Digital pioneered this 
particular protocol, known as the link state protocol or the IS-IS protocol 
which is on the ISO standards track. 

This chapter first considers the problem of assigning unique addresses 
for a network that could potentially span all computers in the world. Then, 
it looks at the basic data and error packets. Next, it looks in detail at the 
DNA Routing Module, the implementation of the network layer on an inter- 
mediate system. The routing module consists of two sublayers: the subnet- 
work dependent and independent sublayers. This chapter looks at the 
different components of each of these sublayers and how they carry out the 
functions of the ES-IS and IS-IS services. 


Addresses, Areas, and Domains 


To provide compatibility with existing systems, ISO has defined a variety of 
different authorities who can allocate addresses. This hierarchical address 
allocation scheme allows allocating authorities to handle the specifics 
within their environments, yet keeps a standard address format for the in- 
terchange of data packets. This system is much like the international tele- 
phone network, where a U.S. user (with a seven digit number plus a three- 
digit area code) is able to call other countries that have different length 
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phone numbers and different ways of allocating the digits within the num- 
bers. 

The first part of a network address is an Authority and Format Identifier 
(AFI). It identifies the authority, as well as the encoding method used for 
the address that follows. The allocating formats that have been defined for 
network addresses are as follows: 


¢ X.121—a CCITT numbering plan for public data networks. 

¢ Data Country Code (DCC)—an ISO-administered unique ID based on 
geographical location. 

¢ International Code Designator (ICD)}—an ISO-administered unique ID 
based on organizations. 

¢ F.69—CCITT standard for telex addresses. 

e E.163—CCITT numbering scheme for public switched telephone net- 
works. 

¢ E.164—CCITT standard for numbering in an ISDN environment. 

¢ Locally administered address. 


Locally administered address formats, while legal, make it much more diffi- 
cult for a remote intermediate system to decide how to reach the locally 
administered domain. It would be the equivalent of making up state 
names (and leaving off country names) in an international postal system. 

After the AFI, the address has an Initial Domain Identifier (IDI). The IDI 
is given to different organizations by whichever authority is specified in the 
AFI. Together, the AFI and the IDI are known as the Initial Domain Part 
(IDP). In the United States, the American National Standards Institute 
(ANSI) is the registration authority for many IDPs. 

Following the initial domain part of the address is a Domain Specific Part 
(DSP). An organization would apply to an authority for an allocation of an 
IDI. Within the IDI, the organization would be responsible for allocating a 
unique domain specific part of the address. 

An organization would presumably obtain a single IDI allocation for all 
its different computers, DECnet or non-DECnet. DECnet nodes then have a 
specific format for the domain specific part (or at least the last 9 bytes of 
the DSP). It is possible that the organization would use other information 
in the leading portion of the DSP that would divide nodes up by geographi- 
cal or administrative areas or by network type. In Figure 3-4, we see how 
the different portions of the OSI address are formatted for use in a Phase V 
DECnet. The last 9 bytes have the three portions shown: the local area indi- 
cator, the node ID, and the selector. We will look at each of these pieces of 
the DECnet version of the OSI address in more detail in later sections. 

Figure 3-5 shows how different format addresses get encoded. Notice 
that all addresses are less than or equal to 20 bytes. The network layer is 


62 Analyzing DECnet/OSI Phase V 





Authority and 
Format 
Indicator 







Initial 
Domain 


Part Initial Area 


Domain Address 
Identifier 


Domain 
Specific 
Part Local 

Network Address 


Selector 3-4 
ISO Address Format 












AFI Value IDP Length Maximum 
IDI Format | Pad IDI Pad IDI DSP 
ith 0 ith 1 Decimal Octets Length 
: (Octets) 







PCIat SPR Bes 7iawt ede See) «ts | ee eee ee 
eee ee Eee oleae ie ise 
41s WSS TS ! 
1E.164 | 
47 












[iso pec_| 
[reo | 
exes | 
[so 16D _| 


3-5 ISO Address Encoding 


Network Layer 63 





responsible for taking an incoming packet in any of these formats and read- 
ing it so that it can then decide how to forward the packet. 

An address can be represented as a string of decimal digits or binary 
octets. In binary encoding, a semioctet (4 bits) is used for each of the digits 
of the AFI. A digit of 8, for example, would encode as 0100. 

After the AFI is encoded, it is necessary to pad the initial domain indica- 
tor (since the IDI can be of variable length). A different AFI is allocated for 
padding with Os or 1s, allowing the network layer to determine which kind 
of pad is used. The pad takes a variable length IDP and appends either Os 
or 1s to make it the maximum possible length (thus allowing the DSP to be 
easily identified). 

This somewhat complicated procedure allows a variety of different ad- 
dressing schemes to be used, each of them guaranteeing that each node in 
the world wide internetwork has a unique address. In a DECnet, the binary 
encoding is used, with a pad of 1. DNA nodes, however, are fully capable of 
processing and generating the other address formats when communicating 
from non-DECnet nodes. 


Networks and Areas 


Before we continue with the question of addressing and the corollary ques- 
tion of finding a particular address, we will look at a conceptual model of 
how a network is structured. The basic goal of this structure is to be able to 
find any node on the network and to get a packet of data to that node. 

We start by dividing the networks of the world into public and private 
networks (see Fig. 3-6). The public network is simply a publicly adminis- 
tered subnetwork, such as a national X.25 network. The private network is 
the collection of subnetworks under the control of some organization. Al- 
though it is an oversimplification, one can think of the public network as 
the means used to connect different organizations together. In this book, 
we concentrate on how an organization builds up its private network. 

A public network is one that offers dynamic data links. Dynamic data 
links offer full connectivity between any two private networks. In this 
sense, subject to security and access control, the world is one big network. 

We assume all networks, no matter how administered, share a unique 
address space as defined by the OSI-compatible network address. A given 
computer might be on both a public and a private network. Such a com- 
puter is the gateway to the outside world. 

The real difference between the public and the private networks is how 
much information is transferred within the network layer about the differ- 
ent paths between different nodes. The public network offers full connec- 
tivity, but it is not quite so dynamic in the exchange of routing control 
information. 
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3-6 Private and Public Networks 


Inside Private Networks 


Inside a private network, there may be a variety of different paths between 
nodes (see Fig. 3-7). Although the choice of different paths is transparent to 
the end system, it is important information to the intermediate systems or 
routers. The intermediate system must respond to topology changes when 
a line goes up or down. When there are multiple working paths, the inter- 
mediate system must choose the best one. One way of making the choice 
easier is to split the private network up into routing areas (see Fig. 3-8). 
Remember that one portion of the DSP of a DECnet address is the local area 
indicator. 

Because of areas, routers are able to specialize. A level 1 router knows 
how to get to every node within its own area. A level 2 router knows how 
to get to other areas, but not how to get to the individual nodes in those 
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3-7 A DECnet Area 


remote areas (although many level 2 routers do double duty as a level 1 
router). 

This hierarchical routing scheme makes it easier to route information. 
An end system will send a packet of data over the Ethernet to its nearest 
level 1 router (known as the designated router). The level 1 router will 
examine the IDP and the local area indicator of the address. 
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3-8 Multiple DECnet Areas 


If both the IDP and the area match the address of the router, then the 
destination node is in the same area as the sender. The intermediate sys- 
tem will examine its routing tables and choose the appropriate subnetwork 
to use to send the data. If the IDP or the area indicator are different, how- 
ever, the level 1 router will forward the packet to a level 2 router. The level 
2 router will examine its routing tables and decide the best path to use to 
get it to the destination area. The destination area might be part of this 
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private network, or may have to cross several public networks to reach a 
different routing domain. 

Eventually, the packet will be forwarded to the destination area using 
level 2 routing. There, the packet will be handed off to a level 1 router that 
will get the packet to its eventual destination. Note that an area can be 
quite simple, as in the case of a single node or a single Ethernet. The area 
can also be complex with hundreds of nodes and a variety of subnetwork 
technologies. 

The concept of a routing domain, or private network, can also be simple, 
as in the case of a single end system attached to a public network. It can 
also be complex, reaching the limit of the 2-byte area space. Several private 
networks can be administered by the same group, leading to a potential 
network size that is virtually unlimited. 

The total number of possible areas in Phase V of DECnet represents a 
distinct difference from Phase IV. In Phase IV, there was a maximum of 
1023 nodes per area and 63 areas in a DECnet. Phase V has a virtually 
unlimited address space (the Phase V limit is 280 quadrillion nodes). 

This Phase IV limit of 64,449 nodes may not sound like a problem, but 
the limits were quickly surpassed in two instances. First, extremely large 
corporate networks, such as Digital’s internal EasyNet quickly outgrew the 
63 area limit. Second, the limit was achieved in scientific and research 
communities when several different organizations tried to combine their 
networks into a common research environment. For example, the High-En- 
ergy Physics Network (HEPnet) combines physics groups all over the world 
into a common DECnet. Although an individual research facility is of mod- 
erate size having hundreds or a few thousand systems, the aggregate num- 
ber of systems used by the high-energy physics community can easily 
overrun the address space. 


DECnet and NonDECnet Nodes 


The concept of public and private networks allows other vendor’s networks 
to be reachable from a DECnet private network, as long as they comply 
with the OSI address scheme. The public network forms the bridge. It is 
also possible for other vendors equipment to be part of a DECnet area, typi- 
cally as an end system. In order for the node to be a part of the DECnet 
area, it must follow several addressing rules. 

First, the address, minus the last byte, must be unique. The last byte, 
called the selector field, is used by DECnet nodes to decide which user of 
the network service should get the data. In a strict OSI environment, the 
user is always the OSI transport service. In a Phase V network, there is 
another transport service, called the Network Services Protocol. Thus, the 
selector field is an address for the next layer user. The implication of this is 
that end systems from other vendors cannot use the last byte of the address 
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as a way of making nodes unique. The concept of a selector field was not 
present in original OSI network layer specifications, but was added into 
drafts on IS-IS routing. 

A second limitation is that the DSP of the address must be at least 9 bytes 
and that the area portion of the address must match that of a neighboring 
router. A DECnet area can be known by up to three different area ad- 
dresses, allowing some flexibility in incorporating non-Digital end nodes. 

If the area address does not match, the end system can still participate in 
a Digital private network, but it must do so as a separate area. In other 
words, routing to it will not be quite as efficient, although connectivity is 
still preserved as it would be to any other private network via level 2 rout- 
ing. 


Basic Data Delivery Function 


Let us assume for the time being that, using a series of subnetworks, a 
given router knows how to deliver a packet to a destination node. The first 
compatibility question is whether the packet can be read by the destination 
node. The format of a data packet is specified in the ISO standard 8473 (see 
Fig. 3-9). If two nodes share ISO 8473 compatibility, we know that at the 
network layer of the network they can exchange data. They must also have 
some upper layer service protocol in common, such as FTAM, if they are to 
do useful work. 

The OSI-compatible address assures us that we can find the node. The 
compatibility with ISO 8473 assures us that the destination node can read 
the packet. In Figure 3-9 we see that both data and error packets share a 
common format. A lifetime indicator indicates how long the packet should 
be considered valid. Each intermediate system that receives the packet will 
decrement this number by at least 1. If a router brings this number down 
to 0, the packet can be considered worthless and is discarded. Note that a 
router will always decrement the lifetime indicator by at least 1. If the 
packet is held for more than a half second, the indicator is decremented by 
2 or more units. 

Following the lifetime indicator are the control flags. The flags indicate 
whether, after determining that a particular subnetwork needed to forward 
the packet has a small packet size limitation, an intermediate system can 
segment the packet. The flags also indicate there are more segments to this 
packet (i.e., if it was segmented by a prior router). Reassembly of packets is 
not done until the packet reaches its ultimate destination. 

The error report requested flag indicates if an intermediate system 
should attempt to send an error report if it has to drop the packet. It might 
drop the packet if the destination is unreachable, if there is an error in the 
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header format, if the lifetime indicator expires, or for a variety of other 


reasons. 


Note that both the error report and the data packet are a best-effort deliv- 
ery service. There is no guarantee that the data packet will be delivered. 
Network layer modules attempt to forward packets, but if buffer overflow 
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or a line goes down, the network layer makes no attempt to recover that 
particular packet. Because an error report is a packet, there is no guarantee 
that an error report will be sent if the original packet was discarded. If the 
error report is sent, there is no guarantee that it will reach the original 
sender of the data packet. 

Following the flags is the segment length—the total length of this seg- 
ment. The segment offset, given later in the header, indicates where this 
particular segment fits into the original data packet. 

There are three other relevant pieces of information in the header (aside 
from the data). The header checksum is used to check the integrity of the 
header and is set to 0 in a DECnet network. If a checksum is received from 
a non-DNA node, it is checked. The data unit identifier is provided in the 
case of segmentation and operates as an identifier for the packet. This way, 
if two different packets are segmented, the destination node can keep track 
of which segment belongs with which packet. The DECnet routing layer 
keeps track of which data unit identifiers (DUIs) were last used for nodes 
that it is communicating with. Each node has a DUI counter, and the 
counter is incremented every time a packet is sent. 

A separate DUI is used for each node instead of keeping a single DUI 
counter and using it for all nodes. If there are high-bandwidth links and 
low-bandwidth links, it is possible that a single DUI counter could wrap 
around (because of the high-bandwidth link) and thus generate a duplicate 
DUI for the low-bandwidth destination. 

If a node is communicating with a very large number of destinations, it 
may not be possible to keep a separate counter for each destination. In this 
case, there is a “leftover” counter used for all nodes that would have ex- 
ceeded the size of the DUI counter cache. 

The last part of the packet header is the options section. The OSI stand- 
ards define a wide variety of different options, each encoded using a code, a 
length, and a value. As a general rule, DECnet nodes ignore most of the 
options available. For example, instead of the option-specified quality of 
service, DECnet nodes use the routing decision process to decide which 
route a particular packet should take. The priority indicator option is also 
ignored. 

Figure 3-10 shows an example of an ISO 8473-compatible data packet. 
Notice that the packet has a remaining lifetime of 20 seconds, measured as 
40 half-second increments. In other words, this particular packet could go 
through another 40 intermediate systems before expiring. 

The packet is a data packet and has segmentation permitted. Notice that 
the packet has not been segmented, since the segment length is equal to the 
total length of 121. Notice also that the data portion of this packet is ISO 
transport layer. 
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3-10 ISO 8473 Data Packet 


Hello Packets 


We now move on to the question of how to find a particular node on the 
network. The easiest case is when the node is on the same subnetwork. If 
we know that a desired end system is on the same subnetwork, we can 
send data directly to it and alleviate the need for using an intermediate 
system. In fact, in this case, we could have a network with no intermediate 
systems. 

Identifying neighbors is also necessary to find intermediate systems. An 
end system needs to know of at least one intermediate system to which it 
can hand off packets with unknown destinations. Neighbor identification 
lets the end system find this default intermediate system. 

Neighbor identification is done via hello messages, a PDU defined as part 
of the ISO ES-IS routing exchange protocol. The ES hello is used to inform 
intermediate systems of the presence of an end system. The IS hello tells 
the end system about the presence of the router. In addition, Digital has 
defined a private IS-IS hello to inform routers about each other. 

Figure 3-11 shows the format of the ES hello message. The packet format 
includes a holding time, which indicates for how long the presence of this 
node is valid. The packet also includes one or more source addresses for 
this node, containing the network addresses. The data link header will con- 
tain the data link address. In this way a node can build a cache that con- 
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Source Address 


tains the network address of the destination as well as the corresponding 
data link address to use to get to that network address. 

The IS hello message is shown in Figure 3-12. In addition to the other 
fields, this packet contains an ES configuration timer. This option tells an 
end system how often it should send an ES hello. In a stable topology, the 
ES hello just adds overhead and we want the timer set as high as possible. 
In an unstable topology, however, the ES hello is crucial to inform the rout- 
ers about the end node’s presence. 

Because network layer packets are not guaranteed for delivery and be 
cause destination nodes may be temporarily out of resources, there is the 
possibility that any given hello message might be lost. One of the assump- 
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tions of the architecture is that a message will not be lost several times in a 
row, that maximum number of lost times being called the holding multi- 
plier. 

When an IS decides there might be a network partition or merge, hence a 
need to find out about the current configuration quickly, it broadcasts a 
new IS hello with a (lower) ES configuration timer. It sends out that mes- 
sage holding multiplier times ensuring that all nodes receive it. When an 
ES receives this message, it adjusts its ES timer downward. It then sends 
out holding multiplier ES hellos, ensuring that the IS knows about its pres- 
ence. If during that time it receives a new, even lower, suggested timer, it 
immediately adjusts its own timer. If it receives a higher value, however, it 
keeps the present lower value to ensure that no IS loses information. 

The low value of the ES timer is only kept for a period of time. With the 
IS hello message, there is an expiration timer for the new value of the con- 
figuration timer. Once the expiration timer expires, the ES reverts back to 
the default value in its configuration. 

An option on hello messages for point-to-point links is verification. It is 
possible that a link will come in dynamically over X.25. Each node has a 
management parameter indicating whether verification is required. If so, 
the hello message must contain the verification option with the correct 
value. The value, a password, is compared against the stored value before a 
link will finish initializing. 

Figure 3-13 shows an end system hello message. Notice that this packet 
uses the IEEE 802.3 format at the data link control layer. The logical link 
control include an addresses of FE, which corresponds to the OSI network 
layer (as opposed to IP for TCP/IP or the Phase IV DNA Routing Layer). 

The packet has a holding time of 125 seconds. Presumably, before the 
125 seconds have expired, this node will have sent another hello message. 
The packet contains a single network-layer address, represented here in 
hexadecimal format. 


End Systems and Caches 


It is possible for an end node to have more than one active data link. Since 
the end node does not have a decision process, it does not have a forward- 
ing database. Instead, it uses two types of information to decide on which 
link to send a packet: 


® manual information 
° reverse path caching 


For a given packet, manually entered information always takes prece- 
dence over the dynamic information. The end node looks for any manual 
adjacencies to use for a given destination, performing load splitting if possi- 
ble. If there is no manual information, the node uses the end node cache 
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(see Fig. 3-14), whose construction is based on the receipt of IS and ES hel- 
los, as well as redirect messages on broadcast links. 

The redirect packet is an instruction from an intermediate system that 
another IS should be used for a particular destination. If an intermediate 
system receives a packet and sends it back out the same subnetwork, it 
should not have received the packet in the first place. Rather than continue 
to perform this superfluous service, it sends the packet, but also sends a 
redirect packet which contains a suggestion that for a given destination an- 
other router should be used (see Fig. 3-15). The end node (or intermediate 
system) will use this information to update routing tables. The end node 
cache assures that the end system can avoid making that same mistake of 
sending a packet to the wrong router. 

In addition, the end node will probe all other circuits to see if they are a 
potential path to a destination. Every few packets, the end node will send 
an extra copy of a data packet down these other circuits. The receipt of a 
redirect message, hello, or data packet will confirm whether or not this cir- 
cuit is a possible path to the destination. 

If the destination node is not directly attached to the end node, but there 
are multiple paths in the cache, load splitting is performed on all applicable 
circuits. Load splitting means that if there are multiple paths (up to four 
total) with the same cost, packets alternate on all the equal, best-cost paths. 
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3-16 Update Process 


If the destination node is not in the cache, a copy of the packet is sent down 
every circuit. Presumably, a hello, redirect, or data packet will result, up- 
dating the cache for the next time a packet is to be sent. 

The transport layer has the option of setting a “try hard” flag on a packet. 
This flag directs the end node to invalidate all cache entries for that destina- 
tion. The packet will therefore be sent down all possible circuits until the 
cache is reconstructed. 


subnetwork Independent Sublayer 


Figure 3-16 shows the basic components of the DNA routing layer. The 
routing layer is broken up into two sublayers. The subnetwork inde 
pendent sublayer operates at a high layer of abstraction, knowing only 
about the presence of broadcast and nonbroadcast links. The subnetwork 
dependent sublayer is responsible for managing functions that differ de 
pending on the type of data link in use. For example, initializing an HDLC 
circuit is quite different from initializing a CSMA/CD LAN. 

We start first with the subnetwork independent sublayer, in which there 
are four major processes in operation: 
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° receive 

° update 

° decision 

¢ forwarding 


The receive process takes incoming packets and allocates them to one of 
the other processes. If the packet has reached its final destination, it is 
given to the appropriate transport layer module. If the packet is destined 
for another node, it goes to the forwarding process. 

Control packets are either handed back to the subnetwork dependent 
layer or to the update process. Link state and sequence number packets are 
part of the ISIS routing exchange protocol and are given to the update 
process. Other control packets, such as Exchange ID (used for password 
. exchange among other things) and hello packets are handed back to the 
subnetwork dependent sublayer. That sublayer maintains a database of ad- 
jacencies, which is used by the update process. 

The update process is responsible for maintaining a list of all links and 
nodes in an area, as well as all paths to other areas if it is a level 2 router. 
The Link State Packet is the primary method used to do this. Sequence 
Number Packets are used to ensure that all routers have all Link State Pack- 
ets. The Sequence Number Packet is thus a form of acknowledgment. 

The decision process takes the link state database from the update proc- 
ess and the adjacency database from the subnetwork dependent sublayer 
and decides the best path to any given node. This forwarding database is 
then used by the forwarding process to decide which adjacency to use to 
forward a packet to a particular destination. 


Update Process 


The update process is one of the most complex in the network layer. Its 
function is to ensure that, within a DNA routing domain (or area), every 
router knows about every other router and every end node. 

To begin, all routers exchange IS-IS hello packets (see Fig. 3-17). The 
packets allow two neighbors to identify each other as routers and identify 
which types of routers they are. The packet includes version numbers and 
minor version numbers (known as Engineering Change Orders or ECOs). 
In addition, the packet contains identifiers indicating which type of router 
is sending the information. The node can be a Phase IV or Phase V router 
and, for each of these, a level 1 or level 2 router. It is possible to be both a 
level 1 and a level 2 router. . 

The packet also contains a bid for the designated router. The designated 
router is the router on an Ethernet that receives, by default, traffic from 
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end nodes. The packet also contains all valid area addresses, any routing 
neighbors, and an indication if the node is a designated router. 


Link State Packets 


Each router on the network constructs a Link State Packet (LSP) which con- 
tains information on all neighbors of the router and the cost of reaching 
those neighbors (see Fig. 3-18). By exchanging LSPs, every router knows the 
current status of every other router and of that router’s neighbors. This 
information is then used by the decision process to calculate the shortest 
path(s) between any two nodes. 

As seen in Figure 3-18, the LSP includes a sequence number. It is possi- 
ble that a given node will not be able to fit all the information into a single 
LSP. The sequence number allows the recipient to distinguish the different 
parts of the sender’s link state database. 
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The packet also includes an indicator showing whether the packet is op- 
erating at level 1 or level 2. The level 1 packet includes a list of all router 
neighbors and end node neighbors. The level 2 packet includes a list of all 
area neighbors. Remember, the level 1 and level 2 decision processes oper- 
ate separately. 

To ensure that LSPs are propagated throughout the network, DNA uses 
an explicit acknowledgment scheme based on the concept of a Sequence 
Numbers Packet (SNP). Two different kinds are used. The complete SNP 
(see Fig. 3-19) is used on broadcast links by the designated router and on 
nonbroadcast circuits whenever the circuit initializes or reinitializes. 

The complete SNP covers a range of LSPs received. For each of these 
LSPs, the node includes an eight-octet node ID (consisting of the local area 
and node ID within the network portion of the address) and the LSP se- 
quence number that identifies which of the packets is being acknowledged. 
The checksum of the LSP is also included as an integrity check. 

The beginning LSP ID and ending LSP ID indicate the range of packets 
included in this acknowledgment. If a particular node falls within this 
range and there is an LSP, it will be included in the SNP. Using this 
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method, a node can see whether it is missing an LSP, or has a packet that 


the sending node is missing. 


The partial SNP is used on nonbroadcast circuits as an explicit acknow- 
ledgment of a particular LSP (see Fig. 3-20). Instead of a range of LSPs, this 


partial sequence number message has a specific list. 


Other Inputs 


The update process is responsible for keeping the link state database up to 
date. The basic input to the update process is the LSPs and sequence num- 
ber packets, delivered by the receive process. There are two types of links 
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that do not have LSPs: dynamic data links and circuits that have no DNA 
nodes on them. 

For links that do not have LSPs, the subnetwork dependent layer fur- 
nishes an adjacency database and notifies the update process of any 
changes to adjacencies (see Fig. 3-21). The adjacency database is derived 
from hello messages. It includes an indicator of how long the adjacency 
information can be considered reliable and whether the information was 
manually configured or dynamically received from a hello message. 

In addition to the adjacency database, one more piece of information is 
used: a set of manually configured reachable addresses furnished by net- 
work management. If a destination area or node lies on the other side of a 
public network, a network manager can always enter forwarding informa- 
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3-21 
Adjacency Database 


3-22 
The Link State 
Database 


tion manually. By indicating the destination address and which neighbor 


router to use, we can ensure that any node is reachable. 


The output from the update process consists of the link state database, 
which will be used by the decision process (see Fig. 3-22). The link state 
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database is accessed whenever the decision process is periodically run. In 
addition, the decision process is triggered by the signal of an event, such as 
the receipt of a new LSP with different information or the purging of an 
LSP because its remaining lifetime has expired. 

Along with the link state database, the routing layer keeps a circuit data- 
base (see Fig. 3-23). This includes information about available circuits and 
is especially useful in dynamic data links. Notice that the database includes 
information that indicates how long to wait before reattempting a call, the 
maximum number of call attempts, and how long to wait before clearing a 
call when there is no traffic. 


Decision Process 


The decision process uses the link state database and network management- 
furnished information to find the shortest path or paths to a given node. 
The algorithm used is known variously as Djikstra’s Algorithm (after the 
originator), shortest path first, or link state algorithm. 

Given a series of nodes and links between them, the basic problem is to 
find the best path between any two nodes. To decide which path is “best,” 
the network manager defines a cost for each link. Costs have a default by 
link type or are manually entered by network management presumably re- 
flecting the bandwidth and utilization expected on the link. The best path 
is represented as the lowest total cost path—the sum of the costs of the 
individual links. 

In the early phases of DECnet (based on a different approach, known as 
distance-vector routing), the network layer came up with a single best path 
between any two nodes. In DNA Phase IV, this was modified to allow load 
splitting. When multiple, equal-cost paths are available, alternate packets 
are sent down the different possible paths. Note that the load splitting is 
either a strict round-robin or random basis and does not reflect the actual 
load on the individual links. This is load splitting, not load balancing. 

The result of the decision process is a forwarding database. For each 
destination within an area, the level 1 forwarding database contains the 
adjacencies that can be used to move the packet one hop closer to its final 
destination. The level 2 forwarding database contains a list of address pre- 
fixes, and the adjacency to use for each of those prefixes. 


Internal Databases 


The decision process uses two internal databases as holding areas for the 
algorithm. The paths database contains the results of the decision process: 
the shortest path to a given node (see Fig. 3-24). It consists of a series of 
tuples (records) in the following format: 
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DNA Paths Database 


For every node N, the paths database contains the shortest distance to N 
and which adjacencies (routers) to use for that shortest path. When an en- 
try is entered into the paths database, that entry is guaranteed to be the 
shortest distance to that node N. 

The second database is called TENT, for tentative placement. Each record 
in TENT is being held pending a decision on whether or not it is the short- 
est path to a given node N. A record in TENT also includes an indication of 
whether or not the node in question is an end node or a router. 


Basic Algorithm 


The basic process is as follows. First, the node running the process puts 
itself into the paths database. Since the distance to this node has a cost of 
zero and is therefore the shortest possible. Next, the adjacency database is 
used to preload the TENT database. 

The way the algorithm works is to look for all nodes in TENT at a given 
distance or cost. The first sweep will look for all nodes that have a distance 
of 1 from the node. The second sweep will look for all nodes that have a 
distance of 2. 

When we find a triplet, we continue to scan TENT and combine any 
other triplets for that same node with the same distance; that is, any other 
routes that would fit the load splitting definition of equal-cost paths. While 
going through the TENT database, if we see a path to the node N with a 
longer distance, it is removed from the database. In this way, we are dis- 
carding paths that are not applicable. 

We now add our node to the paths database. If the node was an end 
node, we go back to TENT and look for additional elements with a distance 
of 1. If the node was a router, we go to the link state database and take that 
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node’s LSPs and add them to TENT. In this way, we are adding not only 
the route to a node but all other nodes to which it is in turn connected. To 
convert an LSP to triplets in the TENT database, we must take the shortest 
cost to our router plus the cost to the neighbors of that router to form a 
total cost to the neighbor. 

For each of the nodes in the LSP, we scan the TENT database. If there is 
already a shorter route to that node, the record in the LSP is ignored. If the 
route in the LSP is shorter than the route already in the TENT database, the 
TENT triplet is discarded and the new one added. If the two are equal cost, 
they are combined. 

In this way, we have added more records to TENT. We now go back to 
scanning TENT; looking for nodes with a distance of 1. If we find one, we 
repeat the procedure. If it is an end node, add it to the paths database. If it 
is a router, add it to the paths database and get the LSP and add it to TENT. 

When all records with a distance of 1 have been examined, we look for 
records with a distance of 2, and so on. If there are no more records in 
TENT, the process is completed. 

The level 2 process is identical with level 1, but instead of looking for a 
node we look for an area prefix. Anything added to the paths database now 
consists of area prefixes and the associated adjacency to use. Since the for- 
warding database is derived from the paths database, it too consists of area 
prefixes for level 2 routing. 

There are two possible complications. One is the unattached router. 
There are level 2 routers that are not connected to any other areas, and are 
sometimes known as stub routers. For these routers, the LSP contains the 
infinite hippity cost bit. If the decision process sees that, it only processes 
end nodes in the LSP. 

The second possible complication is the limitation on the number of pos- 
sible equal-cost paths to a given node. If the number of adjacencies in 
TENT is larger than the total number of allowable path splits, one or more 
of the possible paths must be arbitrarily discarded (arbitrarily since they are 
of equal cost). 

Pruning the paths is based on the ID of nodes, circuits, and LAN adapt- 
ers. First, we attempt to throw out adjacencies with the highest node ID. If 
a node has multiple circuits to it, and has the highest node ID, we throw 
out the highest circuit. It is possible to have multiple LAN adapters on a 
single circuit—we throw out the adjacency with the highest LAN address. 

Once TENT is empty, and therefore the paths database complete, we con- 
struct the actual forwarding database (see Fig. 3-25). The forwarding data- 
base is a subset of the paths database: the node in question (or area prefix) 
and which adjacencies to use. The forwarding database also needs one 
more piece of information if it is a level 1 node—the nearest level 2 router. 
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3-25 
Forwarding Database 


Forwarding Process 


The forwarding process takes packets from the transport layer and the up- 
date and receive processes and’sends them down to the data link layer for 
forwarding. The transport layer sends down originating packets; the up- 
date process sends link state and sequence number packets; and, the receive 
process passes along packets destined for other nodes. 

The forwarding decision is based on a portion of the address. The for- 
warding process will look at the address and see if the packet area address 
matches any of the area addresses of the router. If so, the packet stays in 
this area via level 1 routing. Otherwise, it is forwarded using level 2 rout- 
ing. 

For any given node (or area prefix for level 2 routing), the forwarding 
database returns one or more adjacencies. One of these adjacencies is 
picked for forwarding this particular packet, either on a round-robin or ran- 
dom basis. 

If there is no entry for the particular destination address and this is a 
route-through packet, it is dropped. If the error report requested flag is 
included, an error report is generated. If the packet is a local packet, how- 
ever, it is handed off to a random adjacent router. 

The forwarding process is responsible for maintaining the data unit iden- 
tifiers used to identify a packet uniquely in case of fragmentation. The se- 
quence numbers are kept in a cache (see Fig. 3-26). Note that the cache has 
a limited size—a single DUI is used for all nodes that do not fit into the 
cache. 
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Redirection 


One of the jobs of the forwarding process is to notice when a packet is 
being forwarded back out the same circuit on which it was received. If this 
is the case the router should never have gotten the packet in the first place. 
The data or error packet is sent back out the circuit, and an additional redi- 
rect packet is also sent out, informing the sending node of a better possible 
route to the destination. 

The redirect packet includes not only the addresses to use but the length 
of time for which the redirection is valid. The holding time is extracted 
from the LSP holding time. Thus, a node may have used a manually en- 
tered adjacency for forwarding a packet. When that manually entered 
router gets the packet, it may inform the node that there is a better path, at 
least for a while. 


Partial Source Routing 


A special option in OSI is known as partial source routing whereby the 
originating node includes specific routing directions with the packet. This 
is useful when a packet must cross several different routing domains that 
are not sharing a common routing exchange protocol. Partial source rout- 
ing is parameter 200 at the end of a data or error packet. The parameter 
consists of an offset to use for the next network, followed by a list of net- 
work addresses. 

When the forwarding process sees a packet that uses partial source rout- 
ing, it looks at the offset number, then uses that offset to find the next 
applicable network. It then forwards the packet based on that address, up- 
dating the offset number to point to the one after that. If the offset points 
beyond the last network, the partial source routing list has been exhausted. 
At this point, the node goes back to the destination address in the header of 
the packet and attempts to send it directly to the destination NSAP. 
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Congestion Control 


One of the jobs of the forwarding process is to perform congestion control. 
This function is actually performed by four subprocesses: 


° the flusher 

° the originating packet limiter 

° the square root limiter 

* the congestion experienced indicator 


The flusher is responsible for flushing all packets on a queue for a circuit 
or adjacency that is down. By flushing unneeded traffic, bandwidth and 
processing on the network are preserved. 

The originating packet limiter ensures that a portion of the resources on 
a router is available for route-through traffic. This prevents a local user 
from using all resources, leading to buffers filling up and route-through 
packets being dropped. The theory is, we have an investment in the route- 
through packets and it thus makes sense to keep them flowing. 

The packet limiter works on a per-queue basis. For each queue, it only 
allows a certain number of originating data packets to be on the queue at 
any one time, as determined by network management. Note that in many 
cases there will be no originating data packets if the router is a dedicated 
router and all users are on end systems. 

The square root limiter prevents any one circuit from taking up all buffer 
space on the router. A threshold limit is determined for each queue. If a 
packet is added that would exceed the threshold, the packet is dropped (and 
an error message is sent if possible and requested). 

The square root limiter is based on the total number of routing layer 
buffers and the total number of active circuits. The formula is: 


_ | TotalRoutingLayerBuffers 
threshold = | ¥NumberActiveCircuits | 


As an example, consider 4 circuits and 4 buffers. The rule ensures that any 
one circuit does not take more than 2 buffers or 50 percent of the total 
resources. On the other hand, if there are 16 buffers for 16 circuits, any 
individual circuit can have only 4 buffers. 

The last mechanism is the congestion experienced bit. Whenever the 
routing layer sees that a packet sits in a queue with the average queue 
length greater than an architectural constant (usually 1), then the conges- 
tion experienced bit is set in that packet. The congestion experienced bit is 
then used by the transport layer to adjust the window size and thus reduce 
congestion on the network. 
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Receive Process 


The receive process is fairly simple: it forwards packets up the protocol 
stack to the appropriate user. By the time a packet gets there, it has 
reached its ultimate destination. 

In addition to sending the packet up to the transport layer, the receive 
process is also responsible for checking the packet to see that it is in valid 
format and for reassembling any fragments into a complete packet. If a 
packet is invalid, an error message is formulated and given to the forward- 
ing process. 

In addition to transport layer users, a packet may be received for internal 
routing layer modules. An LSP, for example, is given to the update process. 
A Phase IV update message is given to the Phase IV update process. Hello, 
XID, and redirect messages are given back down to the subnetwork depend- 
ent sublayer. 


Subnetwork Dependent Sublayer 


The subnetwork independent sublayer only saw two generic kinds of links: 
broadcast and nonbroadcast. Network layer functions that differ depending 
on the type of data link are handled by the subnetwork dependent 
sublayer. These functions include the following: 


¢ Call setup on dynamically established data links, either based on opera- 
tor demand for static links or on traffic receipt for dynamically as- 
signed DEDs. 

° Data link initialization, including specification of user parameters such 
as maximum block size. 

¢ Determination of adjacency identification, including the NSAP and Net- 
work Entity Title, as well as the type of node: end or intermediate sys- 
tem; Phase IV or Phase V. 

¢ Autoconfiguration of the end node portion of the area address. 

° Identification verification of adjacent nodes. 

° Detection of neighbor failures through polling via hello message ex- 
change. 

¢ Moving messages between the independent sublayer and the data link 
layer by putting in data link specific information (i.e., protocol ID, IEEE 
SNAP, or DDCMP multipoint address). 

¢ Clearing dynamic data links either through operator intervention or be- 
cause of timer expiration. 

° Specification of static routing information on dynamically allocated 
DEDs that do not exchange LSPs. 


Identification verification is done using an XID packet, which is a simple 
way of verifying that two nodes are meant to communicate (see Fig. 3-27). 
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3-27 
DNA XID Packet 


A simple verification code (equivalent to a password) is stored locally in the 
circuit database. When an XID packet is received, the verification value is 
compared to the stored value. 


Static Routing 


LSPs are used in a DNA network to exchange routing information. Non- 
DNA nodes, however, are not able to issue an LSP (unless they implement 
the same IS-IS protocols). This means that the routing database needs to be 
manually updated to include information about these nodes. In addition, 
dynamically assigned DEDs do not have LSPs, and it is necessary to add 
information about these circuits manually. 

On a dynamically assigned DED, there is a management entity called a 
reachable address. The reachable address consists of a series of reachable 
address prefixes (i.e., an area address) that is associated with this particular 
dynamic data link. Associated with each reachable address prefix is a data 
link address, such as an X.25 address. This is the address of the “router” 
that will forward packets for that particular address. A cost indicator is also 
associated with each of these addresses, just as an LSP would include cost 
information for adjacencies. 

When a dynamic circuit is initialized, the subnetwork dependent layer 
will issue an adjacency cost change event for each of the address prefixes, 
which will be transmitted to the update process. The update process will 
then issue a new LSP to inform other nodes on the network about the avail- 
ability and cost of a particular area. 

A second form of manual information is the manual adjacency, used for 
broadcast circuits. Most ISO-compliant end nodes (and all DNA end nodes) 
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3-28 Phase IV Routing Traffic 


will use the ISO ES-IS hello message to inform routers about their presence. 
It is possible that some end systems do not use the ES-IS protocol but do 
conform to the ISO 8473 format for data packets. By entering a manual 
adjacency into the router’s database, we tell the router about these nodes. 

The last form of manual routing information is for nonDNA routers. An 
end system can be informed about the presence of these nodes, allowing 
the DNA end system to work with nonDNA routers on a LAN. Again, man- 
ual adjacency information is only necessary on a LAN since a nonbroadcast 
link has only a fixed, known number of adjacencies. 


Autoconfiguration 


In a Phase IV environment, it was necessary to enter all the addressing 
information for each node manually. In Phase V, it is possible for end 
nodes to configure themselves automatically. 

An end node has a unique 48-bit ID for the LAN adapter. This 48-bit ID 
matches the size of the 6-byte network-layer node ID. All that needs to be 
added is the local area and the initial domain part. This information can 
easily be found from an IS hello message. 

Autoconfiguration works for all end nodes that can read hello messages; 
in other words, nodes compatible with ISO 9542. If a node is compatible 
with the data format (ISO 8473) but not with ISO 9542, it can participate in 
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3-29 Phase IV Intra-Ethernet Packet 


a DECnet as an end node but cannot autoconfigure itself. Autoconfigura- 
tion is disabled for addresses in the Phase IV compatible address space to 
avoid problems with the older protocols. 


Phase IV Compatibility 


DECnet has always been n-1 compatible: A given phase can always coexist 
with the previous phase. A Phase IV network will coexist within a Phase V 
routing domain. Coexistence is based on level 2 routing: Phase IV and 
Phase V intermediate systems do not coexist within a given area. It is possi- 
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ble for Phase IV and Phase V end systems to coexist in the same area. The 
area would run either the LSP or the Phase IV vector routing algorithms. 

The basic data transfer mechanism between the two environments is not 
radically different. Figure 3-28 shows the basic data transfer in a Phase IV 
environment, consisting of data and hello packets. Figure 3-29 shows the 
format for the Phase IV data packet. Notice that the addresses include an 
error report request (or in this case a nonrequest). The packet, although 
somewhat similar to the ISO 8473 data format, is only applicable to DECnet 
nodes—nonDECnet nodes cannot read the packet format. 

Phase V DECnet nodes are able to read incoming Phase IV packets. This 
means that two DECnet nodes, assuming they share common applications, 
will be able to communicate across the area boundaries. A Phase V node, 
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3-31 Phase IV Level 2 Routing Message 


for example, could use the Data Access Protocol to access data residing on a 
Phase IV node. 

Within a DECnet Phase IV area, end nodes make their presence known 
using End Node hello messages (see Fig. 3-30). These messages specify the 
capabilities of that node (i.e., whether multicast traffic is accepted). The 
level 1 routers use this information to build their cache of end nodes. 

Figure 3-31 shows the message a Phase V intermediate system would re- 
ceive. It indicates the reachable Phase IV areas that are available using this 
particular router, and the cost to reach that area. Areas 2 through 7 have 
costs of 1023, which is equivalent to an infinite cost in Phase IV. 

In a typical transition environment, the Phase IV level 2 router will also 
double as the designated level 1 router. Figure 3-32 shows the Ethernet 
router hello message which is transmitted periodically to all nodes on the 
Ethernet. Using this message, the Phase IV end nodes and routers are kept 
aware of. reachable areas. In order for a Phase IV node to communicate 
with a Phase V node, the Phase V node must be in the Phase IV address 
space. For example, the area indicator needs to be 63 or less or the maxi- 
mum area limitation in Phase IV will have been violated. 

Phase IV compatibility is useful as a transition aid and to maintain com- 
patibility with Digital products that will not migrate into a Phase V environ- 
ment. For example, the PDP-11 systems, often used as dedicated controllers 





Courtesy of Network General 


96 


Bi 2 Set 
Help ie Nid 


Data Length = 78, 


eoee 


eooe 


Version Number = 
ECO Number = 
User ECO Number = 
ID of Transmitting 
Information = 

Gone merea 
nOsioirecctats 

Welch tolateke 

sets -cistere 

ehereten Geneve 


Jet 
Receive Block Size 
Router’s priority 
frea Creserved) 


Hello timer (seconds) 


MPD Creserved)> 
E-List length = 58 


Ethernet Name, reserved 


Optional Padding Length = 1 
Control Packet Format = 6B 


no padding 
= reserved 


Ethernet Router Hello Message 
= Control Packet Format 
Control Packet Type = @5 


reserved 


not blocking request 


multicast traffic accepted 


verification ok 
do not reject 


no verification required 


level 2 router 
1484 
64 


- 
ul 


wunud 
eS 


Router/State length = 42 


Router ID = 1.43 
Priority and State 


a reteetsters 


- 188 6888 


Router ID = 1.48 
Priority and State 


Dersteteterats 


- 161 8688 


Router ID = 1.32 
Priority and State 


1... wees 


Router ID = 1.21 

Priority and State 
Msiere 
- 888 8600 


Router ID = 1.22 
Priority and State 


Lone cone 


- 888 8800 
Router ID = 1.20 


ce 
State known Z-way 
Router’s priority 


De 
State known 2-way 
Router’s priority 


88 
State known Z2-way 
Router’s priority 


88 
State known 2-uway 
Router’s priority 


88 
State known 2-way 
Router’s priority 


Frame 1 of S61 


= 89089080008000 


Use TAB to select windous 


Ey 6Displyuf? Prev 98 Next 
out Dees options® frame frame 


10 New 
captu 





3-32 Phase IV Ethenet Router Hello 


Courtesy of Network General 


Network Layer 97 





in manufacturing or engineering environments, will not have Phase V sup- 
port. N-1 compatibility allows an organization to keep those nodes as a 
Phase IV area and interconnect them to the wider Phase V environment. 


Architectural and Performance Parameters 


Figure 3-33 shows a variety of architectural parameters in a Phase V envi- 
ronment. The first part of the table is a series of default addresses. Some 
of these addresses are multicast addresses for things such as all Phase IV 
end nodes or Phase V end nodes. Other addresses are prefixes and defaults. 
For example, the Hiord constant is a prefix: A Phase IV node uses this con- 
stant to form a 48-bit LAN address. The default area indicator is another 
default: If a node does not know which area it is in, it will use this number. 

Other portions of the table are default values for things like timers. For 
example, the ESCacheHoldingTime specifies that an end node will maintain 
a cache entry for 600 seconds before discarding it as too old. 


Summary 


Figure 3-34 shows a high-level diagram of the routing layer in Phase V that 
reflects the major components. The subnetwork dependent sublayer han- 
dles questions specific to a given subnetwork. Verification of a data link 
and a neighbor and autoconfiguration of area addresses, for example, vary 
depending on the broadcast or point-to-point nature of a link. 

The subnetwork dependent sublayer also handles the question of dy- 
namically established data links. The routing process only sees a link with 
a given cost. If it decides to use that link, it sends the packet down to the 
subnetwork dependent sublayer. That sublayer will, if necessary, activate 
the dynamic link. When the link has been idle for a specified amount of 
time, it will clear the dynamic link. 

Above the subnetwork dependent sublayer are the four components of 
the routing process. These four modules work the same way, irrespective 
of the underlying data links. 

The receive process is responsible for reassembling packets that have 
reached their destination, then distributing packets. Data packets at their 
final destination go up to the transport user indicated in the selection byte 
of the network address. Subnetwork-dependent packets (such as hello and 
XID) go back down to the lower sublayer. If a redirect packet needs to be 
sent out, it is also sent down. 

The forwarding process takes any packet and decides, using the forward- 
ing database, which subnetwork to use. It then hands the packet down to 
the lower sublayer, which handles the mechanics of getting it ready to send 
out over the subnetwork. 
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MaxPathCost 1023 
Quantity to be prefixed to the 16-bit 
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AllIVL1Routers AB-00-00-03-00-00 DNA Phase IV level 1 Routers multicas 
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Parameter Value Description 
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3-34 Basic Routing Layer Components 





The two processes that help make the routing decisions are the update 
and decision processes. The update process is responsible for maintaining 
the link state database. That information is periodically transmitted 
through the network using sequence number and LSPs. The decision proc- 
ess uses the link state database plus manually entered reachable addresses 
and adjacency information to generate a forwarding database. The forward- 
ing database contains, at a given point in time, the lowest cost paths to a 
given destination or area. 

At this point, the network layer provides the basic service intended—a 
best-effort delivery service between any two nodes in the network. The net- 
work layer shields the upper layers from having to know the topology of 
the network and from having to adapt to changes in the topology. The 
upper layers can concentrate on direct communication with the destination 
node and do not have to worry about the mechanics of how to get to that 
node. 
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The network service provides a computer-to-ccomputer best-effort delivery 
service. Transmission of a packet is not guaranteed, but the network is able 
to adapt to changes in the topology of the network and find the best set of 
transmission paths. 

The transport layer uses the delivery service of the network layer and 
builds on it to provide a user-to-user dialogue. Incoming data from the net- 
work service, having reached its final destination, is parceled out by the 
transport layer to the individual users. 

The transport layer provides a stream interface (also known as a virtual 
connection) that guarantees the data sent by one user are received by the 
other user in the order received. The transport layer thus provides not only 
error detection (i.e., lost packets of data) but also error recovery via retrans- 
mission of the lost packets. 

The session layer takes the virtual circuit service and integrates it into the 
computer operating system. It lets its users initiate a session, which con- 
sists not only of a virtual circuit but of any operating-system dependent 
functions such as access control. The session control can be considered a 
bridge between the data-transmission facilities of the network and transport 
layers and the functional capabilities of specific applications. 

What makes DECnet/OSI different from most network architectures is 
that Digital supports two different types of transport protocols and two dif- 
ferent Session Control layers, all sharing the common underlying network 
and subnetwork layers (see Fig. 4-1). 

The Network Services Protocol (NSP) is Digital’s traditional, proprietary 
transport protocol. It is used primarily to communicate with Phase IV 
nodes, but it can also be used in a Phase V environment. The OSI Trans- 
port Protocols consist of three classes of service. The most functional, trans- 
port protocol class 4 (TP4) provides essentially the same functionality as 
NSP. TP4 is used to communicate within a Phase V environment and also 
provides interoperability to non-Digital OSI environments. 
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4-1 Phase V Dual Protocol Stack 


Within a Phase V environment, Digital’s proprietary DNA applications 
will use their own Session Control protocol. The DNA Session Control pro- 
tocol is heavily integrated with the DNA Naming Service (discussed in Chap- 
ter 5) and offers some security services not offered in the OSI Session 
Control layer. 

Quite a few different applications fall in the category of Digital proprie- 
tary and thus use the DNA Session Control layer. Many of these, such as 
the Data Access Protocols (DAP) are discussed Jater in this book. 

Applications like DAP use the DNA Session Control and the OSI TP4 pro- 
tocols for intra-Phase V communication (see Fig. 41). Note that even 
though a proprietary Session Control layer is being used, the lower layers 
are often OSI protocols like TP4, the OSI network layer, and data links such 
as 802.3 Ethernets. NSP is used for communication to Phase IV nodes. 

Protocols like DAP are not very useful for communicating in a truly open, 
heterogeneous environment. For this type of network, Digital conforms to 
the OSI architecture. Sitting on top of the OSI session layer is the presenta- 
tion layer, which is split into two sublayers. The transfer syntax specifies 
issues such as encryption and compression of data. The abstract syntax 
specifies what types of information are to be transferred (e.g., integers, char- 
acters, and constructed data types). 

Finally, at the top of the stack, we see a variety of OSI applications. Some 
provide the equivalent services to Digital proprietary protocols. The Digital 
DAP protocols, for example, find their equivalence in the File Transfer, Ac- 
cess, and Management (FTAM) service in OSI. 

This chapter will discuss the transport through presentation layers of the 
network. Application layer issues are deferred to later chapters. This chap- 
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4-2 Transport Layer Virtual Circuits 


ter also deals with the concept of protocol towers—combination of the vari- 
ous available protocols that two applications have in common. If two nodes 
share the same protocol tower—support the same protocols—there is a com- 
munication path between them. 


Network Services Protocol 


The network layer of the stack provided a best-effort delivery service but 
had no concept of users. All packets of data are just sent up to the trans- 
port service. The transport service, in its data header, labels each packet for 
the port to which it is destined (see Fig. 4-2). In this way, the transport 
layer provides a virtual circuit between two users of the network. 

The transport layer thus allows two programs to communicate. Note that 
there may be a large number of end users all sharing this virtual circuit. As 
far as the transport layer is concerned, however, it is providing simple pro- 
gram-to-program communication. 

In addition to just delivering the data, the transport layer ensures that all 
packets are delivered. If a network line goes down, the network layer will 
adapt its routing tables, but not before losing one or two packets. The job 
of the transport layer is to detect such lost packets and retransmit them. 
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The transport layer detects lost and out-of-sequence packets using a se- 
quence number (just as DDCMP did). Note that on many networks this task 
will be straightforward. If two nodes share the same Ethernet, the job of 
the transport layer is to deliver packets since it is almost unheard of for the 
Ethernet to corrupt packets or deliver them out of sequence. In a compli- 
cated network, however, the job of the transport layer is more difficult. 
Complicated topologies may change more often, resulting in lost packets 
which have to be retransmitted. 

NSP uses several strategies to make sure data make it to their destination. 
First, the user of NSP submits messages of potentially infinite length to 
NSP. NSP fragments the messages into packets, and sends them down to 
the network layer. Figure 43 shows an example of the NSP data packet 
format. Notice that the header flags indicate whether this particular packet 
is the beginning or end of a message. If both flags are set, then the mes- 
sage fits into a single packet. 

The NSP header also indicates the destination and source addresses at the 
transport layer for the message. The NSP packet is itself enclosed in a net- 
work layer header, which contains the network layer address of the destina- 
tion node. 

The NSP packet contains, optionally, two acknowledgments. These ACKs 
are for piggybacking acknowledgments of data received from the other 
node. Notice that the piggybacked acknowledgments are of two types: data 
and “other data.” The data channel is the normal pipeline for sending data. 
Some information, such as interrupt messages, may be contained in an 
other data message, which is required to be a single-packet transmission. 
Only one other data message may be outstanding at one time. 

Figure 44 shows an example of an NSP message. The message is a data 
message, with both the beginning and end of the message in the same 
packet. The message is segment number 65, and the remote node has been 
given permission to delay acknowledging. This allows the other end to ac- 
knowledge several packets at once, a procedure known as pipelining. The 
message also acknowledges message number 153 received from the remote 
node. 

Notice that the message contains the indicator “No Process Type Recog- 
nized” indicating that the NSP port is not a well-known program such as 
DAP or another common Digital application. It is also possible for two pro- 
grams, written by a user or third-party vendor, to use the services of NSP. 
In this case, the network analyzer is unable to spot which particular pro- 
gram is being used. 

If there are no data to send to the other node, it may be necessary to 
send an acknowledgment by itself. Failing to send the ACK would cause 
the other node to time out, which would probably lead to an unnecessary 
retransmission of the packet. Figure 4-5 shows the format of the acknow- 
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[1S data bytes] 
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ledgment message; Figure 46 shows a message on the network. Notice that 
there are three basic types of ACK messages: 


® normal data 
e other data 
* connect acknowledgment 


Figure 46 shows a normal data acknowledgment being sent on the net- 
work. It is possible also to acknowledge an other data message at the same 
time. Figure 4-7 shows an expedited acknowledgment message. 


Connection Initiation 


Before a virtual circuit is established, the connection must be properly initi- 
ated. This is accomplished with the connect control message (see Fig. 48). 
Notice that the destination address is not specified on a connection initia- 
tion. This allows the remote site to dynamically assign a port number. In 
order to specify a service, the DNA Session Control uses the concept of an 
object number which is then dynamically mapped to a port number. 

The connection initiation message also specifies the type of flow control 
desired by the initiator. There are three options: 


° no flow control 
¢ flow control based on outstanding messages 
¢ flow control based on outstanding segments 


The flow control based on outstanding messages is an artifact of older 
versions of NSP and is now obsolete. When flow control is being used, link 
service messages are used to give and take away permission to send. 

Figure 49 shows an example of a connection initiation. The logical link 
destination is blank and will be filled in by a return connection acknow- 
ledgment message. No flow control is specified in the message, and the 
maximum segment size is 1459 bytes (indicating this is probably an Ether- 
net). 

Figures 4-10 and 411 show the format and an example of the disconnec- 
tion. As with the connection initiation, the disconnect initiation contains 
user data, in this case a 2-byte code from the session layer indicating the 
reason. 

During normal operation, link service messages (see Fig. 4-12) are peri- 
odically transmitted. The two relevant flags are the link service flags and 
the flow control values. 

The flow control value contains a number used to modify the window or 
number of packets that can be outstanding and unacknowledged. The link 
service flag indicates how that number is to be interpreted. A value of 0 in 
the link service flag means that the flow control value in the packet applies 





| Header Flags 
Destination Address 
Source Address" 


| 
Acknowledgment ACK/NACK Bit | 
Number 


Congestion 
t 
Data ACK Number thiicatos nit 


ee ACRINACK Bit 


The Data Acknowledgment message has the data | 
ACK field first with an optional Other-Data ACK field. | 
The Other-Data Acknowledgment message has the 


Other-Data ACK field first, with an optional Data 
ACK. 


The Connect Acknowledgment message has only the | 
destination address field. a! 


ACK Type Indicator | 


























4-5 
NSP Acknowledgment 





64 

Non-extensible field 

Data Acknouledgment Message 
ae Acknowledgment Message 
divteie ste OG always zero 
Type ~ = 1 CAcknowledgment Message> 
Sub-type = @ CData Acknowledgment Message) 
Logical Link Destination = C@39 
Logical Link Source = 6491 


Data Acknowledgment Number 
Acknowledge Qualifier 
Message Number Acknouledged 


Frame 17 of 561 
Use TAB to select windous 


2 Set 4 Zoom §5 6Disply™? Prev §S Next 1@ Neu 
Eta out tier options® frame Sar Vil =) fer Neh athe 


4-6 NSP Data Acknowledgment 


109 





Courtesy of Network General 


110 Analyzing DECnet/OS! Phase V 


Message Identifier 
Be reremie ere 
-O@1 .... 


14 
Non-extensible field 
Other-Data Acknouledgment Message 
aaterem OL sits Acknowledgment Message 
--.. --0@ = aluays zero 
Type = 1 CfAcknouledgment Message? 
Sub-type = 1 COther-Data Acknowledgment Message) 
Logical Link Destination BC27 
Logical Link Source 
Link Acknowledgment Number 
Acknouledge Qualifier 
Message Number Acknouledged 


Frame 3 of S61 
Use TAB to select windous 


2 Set 4 Zoom #5 | 6Displyg? Prev @S Next 
mark Cra Me 6G eC Meee meee 
4-7 NSP Other Data Acknowledgement 


to the segments of normal data. A value of 1 indicates that the value ap- 
plies to the other or expedited data channels. 

Setting the flow control modification bit in the link service flags is an- 
other way to perform flow control. By setting this bit, a node can override 
flow control by stopping all data from being sent. If a node is temporarily 
busy, it can send link service messages to other nodes it is communicating 
with to ask them to stop sending data. 

We include one additional message, shown in Figure 4-13, called the no 
operation (noop) message. It is obsolete and is included in the NSP specifi- 
cation for backward compatibility. The no operation message, needless to 
say, does not do anything. 

Figure 4-14 shows an example of a link service message. A link service 
message counts as an expedited message and thus is assigned a sequence 
number (in this case 222). Although the link service flags indicate the flow 
control value interpretation is for a segment count, there are no segment 
credits granted to the other node. 
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OSI TP Classes 


The OSI transport layer is broken up into five classes of operation, each 
giving a different class of service. Of these five classes, Digital supports 
three: 


¢ TPO provides minimal features. 

¢ TP2 provides multiplexing of multiple users over a single underlying 
network link. 

¢ TP4 provides both error detection and recovery. 


TP classes 1 and 3 are basically nonexistent, so nonsupport is not really an 
issue. All of the original five TP classes were designed to operate over a 
connection-oriented network service, with extensions for connectionless net- 
work services. Digital only provides the connectionless network service. 

Basic TPO and TP2 are provided simply as a means of connecting to non- 
Digital environments, primarily with the use of X.25 as the underlying sub- 
network. Since X.25 is a connection-oriented subnetwork, provision of a 
connection-oriented network service is not difficult. 

In the more general networking environment, Digital provides a variant 
of TP4, known as TP4 bis, designed to use an underlying connectionless 
network service. A typical computing environment for Digital-to-Digital 
communication thus uses TP4 bis as the basic protocol. 
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We can break the functions of the OSI transport protocol into elements of 
procedure, each signifying a particular function of the transport layer (see 
Fig. 4-15). Notice that all five classes assign a transport layer virtual connec- 
tion to an underlying network connection—in TP4 bis this step is not neces- 
sary. Notice that all classes do provide the basic function of transfer of 
data, segmentation, and reassembly (not to mention connection estab- 
lishment). 

Concatenation and separation allow several upper layer segments to be 
put into a single transport protocol data unit (TPDU) before being submit- 
ted to the underlying network service provider. TPO does not provide this 
service nor does it provide most of the other elements of procedure. 

Notice that in TP4 we see much better error detection and recovery 
mechanisms. TP4, for example, uses a checksum to check the integrity of 
the data. In other service classes, we assume a reliable lower level, such as 
a connection-oriented network service based on X.25. In the other service 
classes, the upper-layer users are responsible for ensuring their own data 
integrity. 

In TP4 we also see that data are retained until acknowledged. If for some 
reason the data are negatively acknowledged (or a timer runs out), the data 
can be retransmitted without notifying the upper-layer user. Once the up- 
per-layer user has submitted data to the transport service, it can be assured 
that the data will be delivered, barring catastrophic errors such as all links 
failing or the destination computer blowing up. 

Figure 4-16 shows the basic format of the transport layer message. The 
TPDU code selects either a normal data message or an expedited data mes- 
sage. For classes TPO and TP1, since only one user can use the virtual cir- 
cuit, there is no need for a destination user address. The sequence number 
is used to number this particular message. 

Figure 417 shows the data acknowledgment message. In the previous 
data packet, we saw that credits were always 0. Credits in the TP protocols 
are granted using the ACK message. The credit indicates how many more 
messages may be sent and unacknowledged. Notice the extension credit 
field used for extended sequence numbering (allowing more messages to be 
outstanding). 

In the TP4 class of service, the parameter section at the end of the packet 
includes flow control information. This information has a lower window 
edge (the lowest sequence number where all messages are acknowledged) 
and the node’s view of what the next sequence number and the current 
credit are. These last two pieces of information allow the remote and local 
transport entity to perform “reality checks” on each other. 

Figure 4-18 shows an example of typical TP4 traffic. First, two data pack- 
ets are sent; then, the remote node sends back two acknowledgments. On 
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the first ACK, the credit value is 9; on the second ACK the credit has in- 
creased to 10, allowing the first node to have more packets outstanding. 

Following the two ACK messages, the node labeled Sun sends out a data 
message. Notice that in the ACK coming back from the node labeled bridge 
the credit value is 32, which is much higher than the credit value of 10 for 
traffic flowing the other way. Two nodes can maintain different credit win- 
dows, depending on their processing power and their view of congestion on 
the network. 

Figure 419 shows the TP connection request and confirmation message 
formats. As in the NSP protocol, the destination address is left blank on a 
connection request and is filled in by the confirmation message. This mes- 
sage also allows the users to select the class of service and to determine 
whether normal or extended format should be used for sequence numbers. 

Of particular interest is the wide variety of parameters that can be in- 
cluded in these messages. Although many implementations of the TP pro- 
tocols ignore most parameters, the parameters do show the potential power 
of the protocols and how they will, in the future, be able to provide sophis- 
ticated negotiation of the parameters of a virtual connection. Five parame 
ters are particularly interesting in this regard: 
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¢ Protection parameters are used for security negotiation. 

¢ Throughput negotiation allows two users to negotiate an acceptable 
level of data throughput. 

° The residual error rate negotiates an acceptable level of uncorrected 
errors. 

* Priority indicates the priority of service needed. 

° Transit delay indicates the acceptable delay in transit for a given piece 
of data. 


Quality of service parameters at the transport layer are only meaningful if 
the underlying network service and subnetworks are able to provide the 
service desired. The transport layer will simply pass the quality of service 
request down to the lower-layer service provider. As we saw in Chapter 5, 
the initial release of Digital’s network layer ignores most of these types of 
parameters. As a result, the transport layer also ignores this type of negotia- 
tion. 

Figures 4-20 and 421 show a typical connection request sequence. In 
Figure 4-20, we see the connection request, followed by a confirmation, fol- 
lowed by a simple data/ACK sequence. Notice that the 13 credits extended 
by the node labeled DG (probably a Data General computer) are fairly lib- 
eral compared to the 1 credit extended by the Ungerman-Bass computer. 

In Figure 421 we see a more detailed view of the connection request. 
The user has left the destination reference blank, as required. We also see 
that protocol class 4 has been requested, with normal sequence numbers. 
The message also indicates the maximum TPDU size of 1024 bytes, which 
corresponds to a typical block of data off a disk drive. Notice also that the 
user of the transport service (the transport service access point) is indicated 
in the options. We can assume that the TSAP “DGC01” is the name of the 
application using the underlying service. 

Figure 421 also shows additional options. In this case, the connection 
request indicates that the 16-bit checksum can be omitted. The other node, 
in the connection confirm, will need to agree with this. 

Figure 4-22 shows the format of the disconnect message. In contrast to 
the NSP protocols, where only 2 bytes of session control data are allowed, 
TP permits 63 bytes or less. It also indicates a reason code (some of the 
possible reasons are shown) and an opportunity to include more informa- 
tion on the disconnection reason. 

Figure 4-23 shows two more TP messages. The reject message is a nega- 
tive acknowledgment and is used when a particular message received has 
an error or when an expected sequence number did not arrive and a timer 
expired. The error message is used when an invalid message is received. 
Typically, either the checksum or the offending part of the protocol data 
unit is echoed back. One hopes this message only shows up during debug- 
ging sessions. 
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Session Layer and Towers 


From the physical through the transport layers, DECnet/OSI presents a uni- 
fied protocol stack. Although there may be multiple options at different 
layers (i.e., different physical media or transport protocols), the options 
combine together to provide a single, integrated network. 


Upper Layers 123 





ec peer eat onan end BO RANA 9 SE. | 
Credits Reject message 
PRR RS estos 
Reference 

Next sequence 
Sequence Number 


For extended format | 
Lengthdnsteator 9) 9 



















TPDU Code + Code = 0111 | 
Credits 


Error message 


Destination | 
Reference 
Reject Cause | 
Number | 


Parameter Code 









: : 


Echo of invalid 





TPDU or checksum _ | 
Bpiincer coca ! oe 
Parameter Length | ISO TP Exception 
Parameter Value _ We yt re aed Messages 


At the session layer, this unity is destroyed and DECnet/OSI becomes two 
separate networks: DECnet and OSI. The DECnet Session Control layer sup- 
ports the Digital proprietary upper-layer protocols, such as the Data Access 
Protocol. The OSI session layer module supports the OSI-compatible upper- 
layer protocols, starting with the presentation, the application support pro- 
tocols (ACSE, ROSE), and finally the Application Entities such as the X.500 
directory or the. FTAM file access protocols. 

The role of the session layer, for either protocol stack, is to integrate the 
transport service into the operating system on which it is running. At a 
minimum, this means providing a method for starting a virtual circuit (a 
transport entity) and assigning it to a particular upper-layer application. 

The session layer can thus be thought of as the visible portion of the 
network. The user of the session layer service requests a session, sends 
data, then releases the session. 

Some session layer services are more sophisticated than the estab- 
lishment and release of the session. For example, the DECnet session serv- 
ice allows the user to request a remote service by name. The Session 
Control layer, with the cooperation of the DNA Naming Service, translates 
the logical name into a network address. 

Other types of services at the session layer are access control, mainte- 
nance of the local node in the network-wide namespace, and a session re- 
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covery mechanism. Which services belong at the session layer and which 
are part of the upper layers is a matter of philosophy. 

The two session layers examined in this chapter, DECnet and OSI, are 
just two of the session layer services operating in a Digital network. The 
LAT protocols, for example, also have a session layer component, as does 
the System Communication Architecture used in VAX Clusters. 


DNA Session Control Service 
The DECnet Session Control layer provides five major functions for users: 


* manages the transport connections on behalf of users 

¢ enforces access control policies 

* uses the naming service to map object names to protocols and address 

¢ given a set of protocols that form different paths to a remote object, 
chooses one of them and attempt a connection 

¢ maintains the set of possible paths in the network-wide namespace 


The session control module in DECnet is made up of three functional 
components: 


* connection control 
¢ address resolution 
e address selection 


The connection control component is responsible for system-dependent 
functions related to transport connections. For example, the transport layer 
can establish a connection (virtual circuit), but it is the Session Control 
layer’s decision whether or not that connection should be permitted. 

In addition to value-added functions (like accepting and rejecting ses- 
sions), the session layer is the interface into the transport layer services of 
sending and receiving data, as well as the mechanics of establishing and 
terminating the virtual circuit. By providing a unified interface, the user 
can deal with one service provider—the session layer—instead of issuing 
calls to different service providers (transport, session, and possibly data 
link) for different kinds of services. 

The value-added services of the connection control component can be 
split into two major functions. First, connection control allows an end user 
to be identified. This function is system dependent, but it basically consists 
of assigning user names or other identifying information to the user. 

The second value-added function is to validate the end user, again using 
some system-dependent function. In a VMS environment, this validation 
takes two forms. In the first form, a password is passed in with the connec- 
tion request, which is compared with the local rights database. The second 
form is the proxy login which lets a remote user from a particular node 
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have rights on the local node without a password. Proxy logins are based 
on an assumption that the remote node has properly validated the user and 
this is not a masquerade. 

The advantage of the proxy login scheme is that a password does not 
have to be sent over the network. The disadvantage is that once a user 
compromises security on one node, he or she has access to other computers 
on the network. Note that this might also be true in a password-based 
scheme since many users store passwords in files or use the same password 
on all nodes. 

Figures 4-24 and 425 show typical session-level traffic. In Figure 424, the 
first message is a session control protocol connect message. The destination 
is an object (indicating that this is the Phase IV version of the session con- 
trol protocol). The destination object 17 is a File Access Listener, which is a 
process on the target node that uses the Data Access Protocol. Notice that 
the source object is a normal user, in this case an interactive user of the 
MS-DOS operating system trying to get files off of a VAX-based file server. 

Figure 425 shows more details of another connection request. In this 
case the destination object is 42, indicating that the destination process is 
the virtual terminal service. The source, once again, is a general user proc- 
ess (in this case the Digital Command Language session of an interactive 
user). 

Note that this particular message includes a user data field, the username 
of the requestor, a password, and an account for accounting purposes. Also 
note that all of these fields are blank. Since this particular connection is 
being used for a demonstration the system has allowed a fairly loose access 
control policy. 


Address Resolution 


The address resolution component maintains the mapping between a node 
name and a set of possible addresses. When communicating with a node, it 
is possible that there are several different paths. For example, a node may 
have multiple Ethernet adapters. Running on the adapters could be Phase 
IV and V routing protocols. The Phase V routing protocol has the option of 
using several different transport layers. 

A combination of protocols that can be used to communicate with a node 
is known as a protocol tower. A simple protocol tower would be 


¢ Phase V routing 
e Transport protocol Class IV 
¢ DNA Session Control layer 


That same node may also have an alternative tower: 


e Phase V routing 
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e Network Services Protocol 
e DNA Session Control 


Note that either of these towers could be used to set up a connection with 
this node. The two towers make up this node’s tower set. In addition to 
the name of the protocol, the tower includes the address to be used. For 
the Phase V routing layer, this would be the network address. For the trans- 
port class, the address would be the transport selector. 

The address resolution component is thus responsible for maintaining a 
mapping between a logical node name and the network towers that are 
available. The address resolution component will: 


¢ Maintain the local tower. 

¢ Compute and cache the paths available through the tower set. 

* Update the namespace attribute for DNA$Towers so remote nodes can 
retrieve the local nodes tower set. 

* Create and destroy naming service soft links used to provide a back- 
ward translation from the address to a node name. 

¢ Map incoming connection requests from a network address into a node 
name. 


The node name is important for several reasons. First, users do not want 
to have to remember network addresses. Aside from convenience, though, 
is the fact that security in a Digital environment is based on usernames and 
node names. A node may have several network addresses and many proto- 
col towers. Getting a single node name simplifies a lookup of proxy logins, 
permissible connections, and other security-related decisions. 

An example of a tower set follows: 


{{{ DNASProtiDSFAL }, 
{ DNASProtiID$SessCtiv3 “‘17=""}, 
{ DNASProtiD$ISOTransportv1 ‘010203040506'H }, 
{ DNASProtiIDSRoutingv3 37-1234:2060:08-00-2B-05-45-1C-42} 


{{ DNASProtiDSFAL }, 
{ DNASProtiID$SessCtiv3.  “17=""}, 
{ DNASProtiIDSNSP }, 
{ DNASProtiD$Routingv3 37-1234:2060:08-00-2B-05-45-1C-42} 


}} 


The basic tower maintained by the session layer goes from the network 
layer up to the session layer—handling the problem of multiple network 
addresses and multiple transport layer protocols. It is also possible to have 
towers that start at the session layer and go up—different combinations of 
application stacks. The user application can request that the DNA Session 
Control service maintain the upper-layer tower in the namespace. 
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When a user (i.e., DNA DAP) wishes to provide services, it passes in a 
valid DNS name and a set of higher-layer towers, starting at the session 
layer. The address resolution mechanism will store this information in the 
tower maintenance database. Whenever a new or changed entry is de- 
tected, the address resolution component will combine the upper towers 
with the local session towers to derive a set of possible communication 
paths. It then compares the derived set with the towers already stored in 
the namespace and makes any necessary adjustments. 

Note that it is possible that an upper tower will start with a different 
session control service: such as OSI. The DNA session control service only 
maintains DNA-based towers; it leaves the others in the namespace. This 
means that, theoretically at least, OSI-based services can register themselves, 
along with their addresses, in the DNA Naming service. 

Before a user application can submit a tower to the session control serv- 
ice for maintenance, it must create a valid naming service name with access 
control on the DNA$Towers attribute set to allow session control to change 
it. It then submits the name of the tower to the session control service. 

The address resolution component thus maintains name to tower corre- 
spondences for itself (the node) as well as upper layers that reside on the 
node. What the user has done is initialize a “towerette” and let the Session 
Control layer fill in the bottom layers. Once the Session Control layer has 
found the possible protocols in common between two nodes wishing to 
communicate, the node will cache this information. 

To compute the path, the requesting object will pass to session control 
the name of the destination object and the requesting object’s upper-layer 
towers. The address resolution will then build two towers: one for the local 
requesting object and another for the remote destination object. The two 
towers are then compared by forming the cartesian product and looking for 
the matches. The result is a tower that contains a protocol ID, the destina- 
tion address, and the source address at each layer. 


Address Selection 


Given the set of possible protocol sequences, the address selection module 
will choose one. It will first order the protocol sequences in a system-de- 
pendent fashion. An example of the ordering would be to give priority to 
TP4 over NSP for a transport selection. Another ordering policy would be 
to select the first protocol that the naming service retrieves. 

Once a set is retrieved and ordered, the protocol sequence on the top of 
the list is tried. If, for some reason, the connection fails, the address selec- 
tion module will keep on trying until the list of protocol sequences is ex- 
hausted. 

Phase IV of DNA uses a six-character node name. The address selection 
module in Phase V keeps a local alias database that translates these six-char- 
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acter node names into a DNS full name. Any time the Session Control layer 
finds a “short” name, it first looks in the alias database. If it cannot find it, 
it assumes that this must be a short DNS full name. 


Services 


The session layer services offered to the user are summarized in Figure 
426. The majority of the services are oriented around the maintenance of 
the tower. For example, an application can issue the KeepMeHere call, 
which indicates to the Session Control layer that it is responsible for main- 
taining an upper-layer tower in the namespace. The session layer will in 
turn issue calls to the naming service to update the address information for 
that application. 
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Other calls enable an application to establish itself as a service provider. 
An application can open a port to the session layer, then periodically poll 
for incoming requests. A poll does not accept a session—the application is 
allowed to examine the data from the poll, then issues a reject or accept 
call. 

For interactive login, the acceptance or rejection will be performed by the 
operating system interactive login process. For other users, each applica- 
tion will enforce the access control policies. A remote procedure call pro- 
gram, for example, would accept and reject procedure execution 
instructions on a call-by-call or session basis. 

Termination of a session can be accomplished either gracefully or 
abruptly. The disconnection request is graceful in that it will first check 
with the transport layer to make sure all data sent were received and ac- 
knowledged at the remote end. The abort connection request immediately 
terminates the session. 

With either the disconnect or abort request, a 2-byte code can be sent 
explaining the reason for termination. Figure 4-27 shows a few of the possi- 
ble reasons for termination of the request. Programs can also come up with 
their own reasons. 


OSI Session Layer 


The OSI session layer is similar in function to the DNA Session Control 
layer—it provides a means for a session to be established and discontinued. 
In contrast to the DNA Session Control layer, however, the OSI service does 
not offer access control or name resolution services. Both security and 
naming are higher-level services in the OSI model. As a consequence, the 
OSI session layer is in some ways simpler than the DECnet service. The 
OSI session layer does, however, provide an additional service in the form 
of a higher level of flow control. 
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Figure 428 shows a basic session layer session. Notice that the first two 
messages are a connect request and accept. After that, however, there is a 
variety of give and accept tokens messages. Tokens are a way of controlling 
the dialogue between two nodes. 

In Figure 4-28 we only see the session layer traffic. There is also a variety 
of lower-layer traffic that has been filtered out. For example, messages at 
the session layer are sent down to the transport layer, which uses inde- 
pendent ACK messages to make sure data packets reached their destination. 
The session layer view of the traffic takes the issues of acknowledgment for 
granted. 

Figure 4-29 shows the basic session layer connect message. This connect 
message specifies that multiple session PDUs cannot be put together into a 
single message being sent down to the transport layer. 

The connect message also includes a token setting item. The possessor of 
a token is the only side able to engage in a particular activity. This figure 
shows four tokens. The data token governs which side is able to send data. 
The activity tokens are a form of checkpoint used in the case of recovery 
operations. The release token indicates which side of the dialogue is able to 
release the session. 

Finally, there are session user requirements. These indicate which of the 
session layer capabilities are needed for this particular session. Exceptions, 
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4-29 ISO Session Layer Connect Message 


for example, allow special messages to be sent regardless of the tokens. Ac- 
tivity management is the checkpointing operation governed by tokens. 
Half-duplex indicates only one side can send data at a time, governed by the 
data token. 

Following the session layer connect message in Figure 4-29 is the presen- 
tation layer connection information. By including several layers of connec- 
tion information in one packet, a great deal of initial overhead for 
connection establishment can be avoided. In this case, the application driv- 
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ing both the session and presentation requests is the X.400 message delivery 
service. Figures 430 through 4-32 show the concept of tokens and activity 
management in action. We can break a session down into a series of activi- 
ties. Periodically within the activity, there are major breaking points. For 
example, a file access regime could be an activity. Access to a particular file 
would be a major break in activity, known as a major sync point. 

There can also be minor breaks, as in the case of the successful transfer 
of several blocks of data. These are known as minor sync points. Activities, 
major sync points, and minor sync points allow two applications to struc- 
ture a session into a series of manageable units. If there is a need to abort 
the session, the two applications, if they agree on where a sync point oc 
curred, are able to recover later. 

Figure 4-30 shows some typical traffic. The node labeled “Intrln” sends a 
give tokens message followed by an activity start indicator. Notice that sev- 
eral session layer activities are concatenated together. The activity includes 
an identification field for future reference. 

After the activity start message, there are three frames of data (possibly 
transmitted by additional transport-layer messages) followed by an activity 
end message. The target node, labeled “Sun” responds with a prepare mes- 
sage that indicates that the other node should prepare for a major sync 
acknowledgment (see Fig. 3-31). The major sync acknowledgment follows. 
The purpose of these messages is to allow both nodes to make sure they 
agree as to when the major sync point exists. In the case of a recovery 
operation, they will both know which data preceded and which data fol- 
lowed the major sync point. 

Figure 432 shows the use of the minor sync point. In addition to the 
give tokens message there are please token messages. These allow a node 
to request that the other node relinquish its tokens. 

Synchronization points are used in tandem with the resynchronization 
services in OSI. The abandon service says that all prior data should be 
abandoned and a new synchronization should be applied. The restart serv- 
ice allows nodes to go back to any point after the last major synchroniza- 
tion. In other words, a major sync point indicates that both nodes agree the 
data are (subject to an abandonment) safe. 
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In the DNA portion of the stack, we saw that the applications rest directly 
on top of the Session Control layer. This means that applications have to 
agree on the proper way to structure data—an issue handled in the presen- 
tation layer of OSI. In the DNA stack, the presentation layer is null because 
the network is DEC-centric: Digital applications know what data look like 
because the universe is fairly small. 
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8427 Sun  @@3SCF+Intr1n@061Bi1 ISO_SS Give Tokens, Data Transfer (6 frames) 
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4-32 Minor Sync Point Give Tokens Message 


In a general OSI environment, we cannot make that assumption. There 
needs to be a way to allow two applications to agree on how information is 
to be represented. In OSI, we split this presentation layer function up into 
two sublayers (see Fig. 4-33). 

The concept of an abstract syntax is an agreement on what data types, 
simple and constructed, are going to be used. Agreement on these data 
types means that applications can then concentrate on the semantics of a 
data exchange. For example, two messaging services can agree that the 
message header data type is constructed of a series of basic data types (typi- 
cally, a series of time stamps, addresses, and character fields). Then, when 
an application wants to send a message, the application can simply indicate 
that a message header will follow. The target application can concentrate 
on the functionality of processing the message header, leaving the encoding 
and decoding to the presentation layer. 

The abstract syntax thus deals in constructed and simple data types. 
How that information is actually represented for a given transfer is the 
function of the lower sublayer. The transfer syntax deals with the issues of 
compression, encryption, and other functions that affect the sending of data 
in a particular session. 

By the time we get to the presentation layer, we have a very high level of 
service in the OSI network. The transport layer deals with the actual deliv- 
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ery of data, the session layer provides synchronization, and the presenta- 
tion layer allows the user to send data as meaningful records that make 
sense to the application. 

The application layer of the OSI network adds a few support services 
before we see actual services such as X.400. These support services are 
known as application service elements. The basic application service ele 
ment is the Association Control Service Element (ACSE), which is the way 
that two OSI applications form an association with each other. Advanced 
versions of ACSE even allow switching of application contexts: Two applica- 
tions could begin by sending messages, then move to FTAM-based data 
transfer within the context of a single session. 

Other service elements include the commitment, concurrency, and recov- 
ery service (CCR). CCR provides the same basic service as the session layer 
synchronization service but over multiple nodes. CCR thus allows an appli- 
cation to make sure resources are available on several nodes and the opera- 
tions are actually performed. CCR is useful in distributed applications such 
as distributed databases. 

The last basic support element is the Remote Operations Service Element 
(ROSE). ROSE, similar in function to the Remote Procedure Call (discussed 
in Chapter 6), allows an application to request that particular operations be 
performed on its behalf. 

On top of all these application service elements are the functional service 
elements, such as X.400, FTAM, or the virtual terminal service. The power 
of OSI lies in the structure at the application and presentation layer allow- 
ing rich, functional applications to be constructed. 
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Figure 4-34 shows an example of an OSI connection request. The first 
line is the tail end of the session layer connection request. The session 
layer user data are the presentation header. Note that several different 
presentation contexts are specified, each one consisting of an abstract and a 
transfer syntax. The use of multiple presentation contexts allows two appli- 
cations to switch rapidly. 

Following the presentation layer header is the ACSE association request. 
The request specifies an application context name and the name of the de- 
sired application (its “title”). That’s it. ACSE is simply a way for two appli- 
cations to get set up. 

Finding the AP title and other such information is the job of the X.500 
directory services. We search the directory services for a node that offers a 
particular type of service, which would then return a network address and 
an AP title. A connection request is then made to that node. 

Figure 435 shows an example of the Abstract Syntax Notation used to 
define and send data elements. At the presentation layer, the command is 
to select a presentation context. Following that is the ASN.1 encoding of the 
data (the 1 indicates this is the first, and so far only, method for specifying 
abstract syntaxes). The ASN.1 definition consists of a constructed data type. 
The first element of the set is an integer, followed by another constructed 
data type, which is a sequence of an integer followed by a time. 


Summary 


Up to the network layer, we saw a single network in DECnet/OSI Phase V. 
In this chapter we saw there are in fact two different networks sharing the 
services of two different transport layers. 

The OSI network uses the traditional OSI stack, starting with the Trans- 
port Protocol, moving up to the session layer, and then the presentation 
and application layer elements. This stack is used for OSI applications such 
as FTAM and X.400. 

The DECnet side of the stack uses the TP4 transport protocol and also 
supports NSP as a way of interacting with Phase IV domains. The DNA 
Session Control layer, through the use of protocol towers, is able to select 
the appropriate combination of protocols. 

Note that protocol towers could be used in OSI, but applications would 
need to be written that communicated with the DNA Naming Service, ex- 
tracted the tower set, and chose the appropriate tower. In the DECnet side, 
the Session Control layer handles all these functions. 

The Session Control layer, in addition to name resolution, handles house- 
keeping. An application registers itself with the session layer, which is re- 
sponsible for maintaining the higher-level tower set. 
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The session layer in DECnet also handles access control functions, a func- 
tion operating at higher layers in OSI. The DECnet access control policies 
are centered around either a proxy login or a simple password-based 
scheme. There is no reason why this could not be extended to support 
public or private key authentication methods in the future. 

At this point, we have two fairly powerful platforms for the provision of 
distributed applications. Before looking at the applications, however, we 
will look some more at the underlying infrastructure on the DECnet side of 
the protocol stack. Things like time synchronization services, terminal-host 
protocols, and remote procedure calls are used to supplement the session 
control service. We will also look in some depth at how names are main- 
tained on the network. We will then look at a few examples of applications 
written for both of these network platforms. 
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Names 


Names are used at many different levels of the network. The data link 
layer uses a 48-bit unique ID to identify stations on an Ethernet. The net- 
work layer uses a 20-byte unique ID, often encapsulating the data link ad- 
dress into the network layer address. Unique 20-byte addresses are suitable 
for programs such as the network layer of a protocol stack, but they pose 
problems for human beings: The address may be unique, but it is difficult 
to remember. Names provide a higher-level, more intuitive form of ad- 
dressing. 

A naming service takes human-readable names and resolves them into a 
series of attributes, such as a network address or protocol tower. This is 
one of the more complex tasks in the network. Complexity is provided by 
the need to enforce uniqueness in the namespace, to allow the namespace 
to function efficiently in a large network, and to take into account the con- 
straints introduced in supporting the quirky nature of human names and 
matching these names to the rigid formats used by network protocols. 

Names exist at four different levels (see Fig. 5-1). The names we have 
been dealing with up to this point have been the bottom two layers: net- 
work addresses and routing information. We have seen it is desirable to 
separate the network address of a node from the paths used to reach that 
address. Since paths change dynamically, we have the network layer trans- 
late a network address into the reachable paths at a particular moment, 
shielding higher layers from the necessity of knowing routing information. 

Just as a particular network address may have many reachable paths, a 
particular node may have multiple towers. A common cause is multiple 
protocol stacks: A Phase V node may have addresses for DNA Phase IV, DNA 
Phase V, TCP/IP, and generic OSI (not to mention a VAX Cluster address 
and possibly even an SNA network address for IBM mainframes). 

A unique name allows a node to be referred to by upper-layer programs 
in the same fashion, no matter what the network address. A unique name 
in the network also lets us continue to refer to the services offered by the 
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5-1 
Levels of 
Naming Services 


same name if it is moved to another computer. Instead of focusing on proc- 
essors, we can focus on service providers. 

Not only do we want unique names for nodes, we need names for pro- 
grams and users. If a user has a unique name, we can move that user from 
one computer to another. The naming service will inform a program (e.g., 
an electronic mail program attempting to deliver a message) of the current 
location of that particular user. 

The service provided by Digital’s DNA Naming Service (DNS) is known as 
a primitive naming service. Given prior knowledge of the unique name of 
an object (e.g., a user, program, or node), the naming service will return an 
attribute of that object, typically the current network address of that object. 

Another level of naming service is known as a descriptive naming serv- 
ice. Its purpose is to resolve attributes into names. One can think of the 
primitive name service as a white pages function and the descriptive serv- 
ice as a yellow pages function. For example, we might want to find all user 
names where the attribute “organization” is equal to “Digital” and the at- 
tribute “organizational affiliation” is equal to “Public Relations Engineer.” 

Digital’s DNS focuses strictly on primitive name translation. The higher- 
level descriptive service is provided by an international standard known as 
X.500, after the CCITT committee that formulated the standard. X.500 is 
also an OSI standard. 

This chapter starts with a detailed discussion of Digital’s DNS. It goes on 
to discuss X.500, its major components, and the relationship to the primi- 
tive naming service. Finally, it discusses the question of the relationship of 
security services and naming services. 


Purpose of the DNA Naming Service 


One of the major functions of DNS is to provide a node name to network 
address translation. The primary user of the service is thus the DNA Ses- 
sion Control layer (see Fig. 5-2). The session control service contains an 
address resolution component, which uses the services of the DNS Clerk. 
The clerk, in turn, queries the naming service for a name-to-address transla- 
tion. 
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5-2 Relationship of DNS and Session Layer 








There are other users of the naming service as well. The Distributed File 
Service (DFS) allows a user to access files without knowing their location. 
When a user requests a file, DFS will query the naming service to find the 
current location of the file. 

It is important to realize that name-to-address translation is not the only 
function of the naming service. We will see that the security services will 
use DNS for storing authentication information. An object has many attrib- 
utes; the network address is just one. 


Structure of the Namespace 


A namespace is a set of unique names. In DNS, the namespace is distrib- 
uted on several name servers, each one managing one or more clearing- 
houses. The clearinghouse is the actual data; the name server is the soft- 
ware used to access the data in a controlled fashion. 

Figure 5-3 shows the components of a DNS namespace. The namespace 
is structured as a tree containing directories. A node in the directory has 
one of three child entries: 


° object entry 
¢ child pointer to another directory 
° soft link 


Object entries have a name and a set of attributes. The most prominent 
attribute is the network address—the current location of the object. We will 
soon examine a variety of other attributes used for management of the 
namespace. 
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5-3 Structure of the Namespace 


The soft link is a pointer that allows the namespace to be viewed as a 
directed graph instead of as a pure tree. A soft link is the equivalent of an 
alias. Although soft links allow the namespace to appear as a general mesh 
structure, it is still really a tree. Each directory thus has only one parent 
and is not a child of one of its descendants. 
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5-4 Naming Service Replicas 


The namespace is a partitioned, partially replicated database. A partition 
of the namespace is a clearinghouse—a collection of directories. A clearing- 
house also has a name, which is very tightly controlled since one must al- 
ways be able to find the clearinghouse, or the naming service becomes 
useless. f 

Replicas allow copies of a directory to be stored in multiple clearing- 
houses. There are three kinds of replicas: 


°* master 
° secondary 
° read only 


Figure 5-4 shows the different kinds of operations that can be performed on 
the different types of replicas. Notice that the master replica is the only 
place a child directory can be created. Other objects can be created on a 
secondary replica. The read-only replica is for lookup operations. It is im- 
portant to note that the user does not see any of these issues; the DNS clerk 
interface shields the replica type from the user. The clerk, in cooperation 
with name servers, will find the appropriate type of replica for the opera- 
tion being performed. 

Replication is a loose consistency guarantee. You may get different an- 
swers at different times or locations because updates are not fully propa- 
gated. Periodically, an operation known as a skulk is performed and brings 
all the replicas into synchronization. 

It is possible that update operations will occur simultaneously on differ- 
ent replicas. To resolve conflicts, an update is always time stamped, and 
the latest one always wins. The time service is thus an important part of 
the naming service infrastructure. Updates have the following properties: 


* Updates are total—every update is applied irrespective of the history of 
past updates. 
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¢ Updates are idempotent—if you apply an update several times, the re- 
sult is the same. 
° Updates are commutative—no matter which order the updates are ap- 
plied the latest one always wins and the result is the same. 
DNS guarantees the integrity of the namespace subject to the above update 
rules. At any one time, updates may not be totally propagated through the 
namespace and the servers may give different answers to different people. 
Over time, however, the namespace will converge to a common view to all 
users. 


Names and Attributes 


A name is a complete path specification starting from the root, consisting of 
the concatenation of the names of each of the objects in the path. Each of 
the objects has a name known as a simple name. The concatenation of 
names is known as a full name. Name servers only operate on full names, 
although many systems will have a local nickname processor. 

It is up to each network administrator to decide how to structure the 
namespace. Presumably, the root would be the name of the organization. 
The next level might be individual divisions. The next might be the cate- 
gory of names, followed by instances. For example, the node Xenophobe in 
the Digital PR group might have the following DNS name: 


DigitalPR.NODES.XENOPHOBE 


“DigitalPR” is the name of a directory; NODE is a subdirectory; and the full 
name above is an object (or possibly a soft link to another name). Other 
organizations might structure their namespace on a geographical basis, on 
the assumption that geography is a more stable label for an object (ie., a 
person) than either organizational hierarchy or function. 

In addition to the set of simple names, the full name includes the Name- 
space Creation Time Stamp (NSCTS), which is the unique identifier for this 
namespace. The use of the NSCTS as part of the full name allows the merg- 
ing of namespaces in the future. Note that people will almost always use 
the namespace nickname instead of the NSCTS. 

Full names have two properties: 


¢ absoluteness 
¢ referential transparency 


Absoluteness means the full name will completely identify one object. Ref- 
erential transparency means that a given full name always refers to the 
same object, no matter which client submitted the request (subject to the 
question of update propagation delays). 
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Names can be referred to in internal or external format. Internal format 
is used across the client interface. External format is used for human be- 
ings. Programs should use the internal format as the external format is 
subject to nickname translation and other potential problems. 

The external format is a namespace nickname plus a sequence of simple 
names. The $ in a simple name is reserved for Digital use. Uppercase and 
lowercase can be mixed—they are preserved for presentation purposes but 
do not affect the lookup operation. 

There is also a quoted name syntax, which allows additional characters to 
be used. For example, if you are importing names that make use of the 
period (i.e., DOS file names) you might want a period as part of a simple 
name. 

The last form is the binary simple name, which consists of “%X” followed 
by a series of hex characters. Note that a binary simple name never 
matches a regular or quoted simple name even if they would encode the 
same. A final rule for external forms of names is that if they start with a 
leading separator (e.g., a period) then all default nickname processing is 
suspended. 

Wildcards can be used on external names. The * matches zero to n char- 
acters; the ? matches 1 character. The ... (ellipsis) matches a terminal sub- 
tree (all parts of the space below). Thus, 


matches all entries. 


Internal Names 


The name server only works on internal names. This consists of the NSCTS 
plus a sequence of simple names. The simple name, in turn, is a flag octet 
plus a counted string. Internal names are treated as opaque by programs. 
A null internal name is equivalent to the root of the tree. 

There are some arbitrary size limits for names. The user should expect 
the limits to go up. A single simple name has a permanent limitation of 
255 octets, including flag and count fields. The arbitrary limit is on the full 
name size; it is currently set at 402 octets including the NSCTS and all other 
characters. 


Attributes 


Attributes can be single valued or set valued. Sets contains no duplicates 
but have no ordering. Three operations are available on set-valued attrib- 
utes: 


¢ Redundant insert: If the value is not present, insert it. Otherwise ig- 
nore the operation, but do not return an error. 
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e Redundant delete: Delete if present, otherwise ignore but do not return 
an error. . 
¢ Full lookup of all values. 


Attributes can be global or class specific. Global attributes apply to all ob- 
jects. 

An individual attribute value is limited to 4000 octets. Because of the 
loose update methods used in the naming server, it is impossible to limit 
the size of a set—everybody could be adding a member at the same time. 

The naming service maintains a tree consisting of objects. Each of these 
objects contains a set of attributes. Some attributes are user created; others 
are system defined. Figure 5-5 shows some architecturally defined attrib- 
utes used in the naming service. 

The first category of attributes is present on all objects. The creation time 
stamp shows when the object was created, and the update time stamp 
shows when this particular version of the object was last updated. A time 
stamp is used in the skulking process to resolve multiple updates on differ- 
ent replicas. The third attribute, the access control set, is discussed later. 

Clearinghouse objects contain a variety of attributes used to manage the 
naming service. For example, the last address attribute is used whenever a 
clearinghouse initializes itself to see if it has moved. Other attributes, such 
as the clearinghouse state and directory version, allow the name server soft- 
ware to perform consistency checks. 


Predefined Objects 
Three objects are predefined: 


¢ DNS$Group 
¢ DNS$Clearinghouse 
° DNA$Principal 


The group object has two class-specific attributes. The DNS$Members is a 
list of members in the group. It contains two fields—a Boolean and a full 
name. The Boolean indicates whether the name is in turn another group. 
The second attribute is the DNS$GroupRevoke, which is a timeout factor. It 
indicates how long a user should cache the result that a member X is a 
member of this group. 

The clearinghouse object is a special class of object that is never modified 
by clients. Associated with this class of object is either a DNS$Address (a 
Phase IV Address) or a Phase V protocol tower (DNA$Towers). The last pre- 
defined object is the DNA$Principal. This is the name of a principal user 
for the purpose of authenticating clients. 
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5-5 (Cont.) Global Attributes 


Name Server Protocols 


The user of the name server uses the clerk interface. The clerk, in turn, 
communicates its request to servers (see Fig. 5-6). The clerk is present in 
every DNA Phase V node. Servers are located throughout the network, al- 
though not on every node. To inform clerks about the presence of servers, 
a solicitation and advertisement protocol is used. Once clerks find servers, 
they use the clerk-server protocol to communicate. A third protocol is the 
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5-6 Naming Service Components 


update propagation protocol, used between name servers to keep replicas in 
synchronization. 
The name server contains four functional modules: 


¢ Name server control contains the management interface and handles 
the solicitation advertisement protocol. 

¢ Transaction Agent handles the clerk server protocol and uses the direc- 
tory maintenance protocol to coordinate directory operations. 

* Update Sender propagates high-priority changes. 

* Update Listener responds to the update sender. 


The update sender and listener are also responsible for making sure that 
clearinghouses can find each other. 


Protocols 


The operations presented to the user are shown in Figure 5-7. The opera- 
tions in the client interface are then turned into messages between clerks 
and servers (or between multiple servers). 

The naming service can operate as either a direct client of the data link 
or as a client of the session control interface using a virtual circuit. If a 
clerk is contacting a server on the local data link, the datagram service 
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would be used. If the server is in a wide-area environment, the virtual cir- 
cuit is used. 

Figure 5-8 shows the format of the message header for request response 
exchanges in both of the environments. Notice that in a virtual circuit envi- 
ronment, there is no need for a sequence number since the underlying ses- 
sion and transport services will deliver infinite length messages. 

All queries to the name service are request/response messages. Each re- 
quest will receive zero or one responses. A request is never retransmitted 
by the clerk, although it might be retransmitted by the underlying virtual 
circuit provider. 

In addition to the request/response messages, there are solicitation and 
advertisement messages. The solicitation is used by a clerk that has just 
initialized and is attempting to find a server. The advertisement message is 
used by servers to indicate their presence on the network. The advertise 
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ment includes the unique ID of the namespace, as well as a list of clearing- 
houses currently active. 

Once a server has been found, the clerk is responsible for taking full 
names as input from clients and finding selected attributes. It is possible 
that a particular server will not have the name desired. Most queries sent 
in by clerks, as well as the responses from servers, contain a progress record 
to help in this situation (see Fig. 5-9). 

The progress record is used to convey hints to clerks on which clearing- 
houses might contain information on the desired name. The record con- 
tains the unresolved (original) name, plus the resolved name after 
translation of soft links. It also includes a timeout indication for any soft 
link information. 

Figures 5-10 through 5-14 show some typical message exchanges between 
clerks and servers. Figure 5-10, for example, is the enumerate attributes 
exchange. The request contains a progress record (which might have been 
the result of a prior search) and an indicator of the maximum size of a valid 
response. The response contains a list of attribute names and values and a 
context name. The context name is used when there are more attribute 
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values than can fit into the maximum size specified. Subsequent requests 
will contain this context name, which will be used to continue the process. 
Context indicators are used to get around the DNS constraint that one re- 


quest must have only one response. 


Operation of the Clerk 


The clerk has six functions: 


send out requests and receive responses 
communicate with one or more servers 


maintain a cache 


maintain credentials needed by client for authentication 
walk the directory tree on one or more servers to resolve client requests 


discover available namespaces and set on one as the default 
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Contacting Name Servers 


To establish communication with a server, the clerk has to perform four 
operations: 


select a likely clearinghouse 

locate its name server 

establish communication 

authenticate the client to directory and vice versa 


Given a particular directory lookup request, the clerk must make a random 
stab at deciding which clearinghouse is the most likely. This random stab 
can be aided by a cache or through the use of the solicitation and advertise- 
ment process. 

The best way is to start with a cached replica set for the parent directory. 
The replica set has all the clearinghouses that contain the information 
needed. Some of these clearinghouses cannot perform the desired opera- 
tion and can be discarded. Some clearinghouses may not give the accuracy 
that the client specified in the confidence argument to the call. If any clear- 
inghouses are left after taking out the ones that will not work, one is cho- 
sen. Otherwise, the clerk will have to walk the tree. 

Once a potential clearinghouse is identified, the clerk needs the network 
address of the relevant name server. This address may be cached from a 
recent communication attempt or cached from listening to advertisements. 
There is also an address hint in the replica set, or the clerk can perform a 
lookup on the name of the server. Once a set of possible network addresses 
is found, one is picked randomly. 

To increase efficiency, the DNS architecture specifies several suggested, 
but optional, optimizations. First, existing virtual circuits can be used. In- 
stead of terminating a circuit after each request, the circuit is kept up. It is 
possible that the name server will sever the connection to reduce overhead. 

A second optimization is to use cached name server entries that have had 
prior success rather than those that are untried. If there is a cache of recent 
failures, those should be avoided. Finally, close name servers should be 
tried over ones that are far away. This means that a server on the local LAN 
should be tried over those multiple hops away. Note that this optimization 
requires the routing layer to inform the clerk of the “distance” of a location. 

Once the network address is selected, the clerk uses either a datagram or 
a virtual circuit service to establish communication. The client call includes 
authentication and addressing information. 


Walking the Tree 


If a clerk initializes with no cache, it may have no idea which clearinghouse 
to use. In this case, the clerk is forced to walk the tree, following pointers 
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through the namespace. Given the address of one clearinghouse, it is possi- 
ble to query the UpPointer attribute of that clearinghouse, looking for an- 
other clearinghouse closer to the root. Once at the root, the client can then 
walk back down. 

When a name server gets a request from a client, it will begin performing 
the request. Periodically, it may return progress records, which indicate 
that another clearinghouse can provide further guidance. 

The progress record has two functions. First, it gives the clerk a new list 
of clearinghouses to try. Second, it encodes information for subsequent 
clearinghouses to help guide their search. A progress record has eight 
fields: 


¢ Unresolved name; the portion of the original full name that is yet unre- 
solved. 

° Resolved name. 

* Clearinghouse list. 

¢ Linked; a Boolean set to true the first time a name server follows a soft 
link. 

° HitLink; a Boolean set to true when the name server hits a soft link. It 
is then returned to the clerk so it can check for loops in soft links. 

¢ Timeout; a timer parameter for soft link caching. 

° Up; set to true if the clerk wants the name server to find the root or 
chain up the tree 

° Ignore state; set to true by the clerk if it wants the name server to ig- 
nore the state of a directory or a replica. Used for low confidence set- 
ting. 


A clerk can use a progress record to formulate a second search. Passing the 
record back and forth also alleviates looped searches because nodes can 
keep track of soft links found and clearinghouses visited. 


Clerk Bootstrapping 


When a clerk initializes, it begins by using the solicitation and advertising 
protocol if the clerk is on a LAN. If the clerk is on a WAN, a manual ad- 
dress for a server (plus the NSCTS of default namespace) must be added. It 
is possible that a name server might have to send out multiple advertise 
ments if the data will not all fit into one packet. A clerk can solicit this 
information but only either within the LAN or the area. The parameter 
solicitation distance parameter sets the limit of the solicitation. 

When a clerk initializes, it must wait at least several seconds before send- 
ing a solicitation. This wait keeps excessive solicitations off of the network. 
After the set period of time (SolicitHold), it then waits a random period of 
time. This jitter prevents all workstations from flooding the LAN at the 
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same time in case of a power failure. This random period of time, which 
prevents synchronized multicasts, has a mean of 3 seconds. 


Clerks and Caches 
Each clerk maintains two types of caches: 


¢ The global cache is used by all clients of the clerk. 
¢ The client cache is specific to each client. 


The global cache contains three types of information. First, there is a 
mapping of a clearinghouse name to the clearinghouse time stamp and ad- 
dress. Second, there is a mapping of directory names to the clearinghouses 
where the replicas are stored. Third, there is the status of name servers. 
Information in the name server status table includes the network address 
and possibly other implementation-dependent information such as the time 
of last contact, the status of the virtual circuit, the last failure, and the dis- 
tance of the server. 

The client-specific caches include information such as attributes of an en- 
try, mapping of soft links to full names, and group membership. The client 
caches may actually be a single cache, as long as a client is not able to 
browse another client’s cache. 


Name Server 


The name server is the software system that manipulates the state of the 
clearinghouse. The clearinghouse is the file or database where names are 
stored and where the structure of the namespace is maintained. We can 
divide the discussion of the name server into five pieces: 


¢ the structure and content of the clearinghouse 

¢ the name server clerk, which provides a superset of the client clerk 
functions 

* the transaction agent, which retrieves and modifies entries in the 
namespace 

¢ the update sender/listener, which is responsible for convergence of rep- 
licas (including skulking) 

¢ the name server control module, which manages the server and han- 

_ dles the solicitation and advertisement process 


Structure and Content of the Clearinghouse 


Each clearinghouse is a separate database. It is possible for multiple name 
servers to access some clearinghouse (as in the case of a VAX Cluster), but 
consistency and atomicity are not specified. 
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A clearinghouse contains six types of information: 


¢ clearinghouse global information 
° directories 

* objects 

° child pointers 

° soft links 

* namespace-wide information 


The clearinghouse global information is stored in a pseudodirectory which 
bears the same Creation Time Stamp (CTS) as the clearinghouse. The pseu- 
dodirectory allows the clearinghouse to be named, and its attributes ma- 
nipulated. Thus, to find a clearinghouse, we simply send in the name, and 
get back the CTS. Namespace-wide information is used when the clearing- 
house stores a directory that was the root of a namespace that has since 
been merged. 


Name Server Clerk 


The name server clerk provides a superset of the functions of the normal 
client clerk. Examples of the new operations are the ability to combine 
replicas, to link up new replicas with others, and to copy an update from 
one replica to another. 

The name server clerk is used by the transaction agent and the update 
sender to manipulate other clearinghouses, thus maintaining the consis- 
tency of the namespace. 


Transaction Agent Module 
The transaction agent module has three responsibilities: 


® processing clerk transactions from clients 

° reading and writing to the clearinghouse 

* communicating with other transaction agents at other name servers to 
synchronize updates 


The transaction module uses two protocols. The clerk-server protocol is 
used to communicate with clerks; the directory maintenance protocol is 
used to synchronize the state of parent and child clearinghouses when di- 
rectories and replicas are created and destroyed. The transaction agent is 
multithreaded. That is, it must be able to handle multiple outstanding re- 
quests. 

When the transaction agent receives a request, it must first determine if 
the clearinghouse is available. If it is, it finds the requested entry in the 
clearinghouse (or returns a progress record). Additionally, the transaction 
agent must authenticate the client access to the directory. 
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A special type of transaction is used to manipulate a directory. To create 
a directory, the clerk must contact the transaction agent that controls the 
clearinghouse that has the master replica for the new directory. Note that 
the master replica for a directory is not necessarily in the same clearing- 
house that has the master replica for the directory’s parent. 

The simplest case of creating a new directory is when the parent and the 
child are both on the same node as the transaction agent. The agent first 
creates the new directory, with a state of “newDirectory” and a pointer to 
the purported parent. Then, the agent goes to the parent directory and, if it 
exists, creates a pointer to the child. Next, the agent goes back to the child 
and sets the “parentPointer” to the actual name (resolving any soft links 
necessary). Finally, the agent skulks the new directory. This gets the ACS 
from the parents, sets the state to on, and sets the directory to operational. 

To create a replica, a similar process is followed. First, the CTS and re 
solved full name of the directory are gotten from another replica. Second, a 
check is done to make sure the local clearinghouse does not already have 
this replica. Next, the replica is created, with a state of “newReplica.” A 
temporary ACS is then borrowed that has at least enough permissions to 
allow a subsequent skulk to work. If the new replica is a secondary replica, 
the epoch and ring pointers are’set up. A read-only does not need this, and 
the master is the original directory. 

Next, the transaction agent uses the clerk to send a request to the transac- 
tion agent, which has the master replica to modify the replica set to include 
the new replica’s clearinghouse. Then, a skulk is initiated to turn the rep- 
lica on. Finally, an attempt is made to modify the child pointers of the 
parent directory. If this does not work, it can be done later. 


Update Propagation 


The update sender and listener together ensure that replicas of a directory 

converge to a consistent state in a reasonable period of time once updates 

cease. Although convergence is guaranteed under normal operation, net- 

work partitions or nonfunctioning servers may prevent (or delay) this. 
There are two basic ways to update replicas: 


¢ skulks 
° propagation 


Skulks have the potential for being expensive. In fact, continually running 
a skulk is prohibitive, so propagation is used to supplement the process. 
The skulker is run periodically but is considered by the DNS architect to 
be the “central critical algorithm for maintaining the structure of the name 
space.” Skulks are done on a per-directory basis. This is because the direc- 
tory is the unit of replication (not the clearinghouse), and the skulk is 
responsible for maintaining the consistency among replicas. It is possible 
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to have several skulks running in parallel. If multiple skulks are initiated 
on the same directory, all but one will self-abort due to an inability to form 
a ring. 

A skulk can be initiated in three ways. First, a client can explicitly start 
the skulk. Second, it can be run on demand by a transaction agent, as in 
the case of creating a directory. Third, and most typical, a skulk is run 
periodically by a name server as a background process. The frequency of 
skulks is determined by the DNS$Convergence attribute for a particular di- 
rectory. 

If a skulk fails repeatedly, this is evidence of corruption in the name 
space. The most probable reasons are that one of the name servers is not 
running or the clearinghouse is off line. More obscure reasons are also 
possible, such as the clearinghouse being destroyed or a major skew in the 
clocks. 

Epochs are a way of forcing all old skulks to fail. When a clearinghouse 
becomes permanently unavailable, it is possible that a skulk will be unable 
to finish. The new epoch reconstructs the entire replica set, resynchronizes 
all copies and recovers as much of the original state as possible. A new 
epoch is used when a master or secondary is destroyed, or when it is neces- 
sary to change the master replica to a new location. 

The skulker process is aided by two other processes—the collector and 
the spreader (see Fig. 5-15). The collector follows the ring of replica point- 
ers for a current epoch. It collects all updates, then uses the combine proc- 
ess to merge them. The spreader then takes the combined update and 
sends them out. 

The propagator is used for high-priority updates that cannot wait for a 
skulk. Although the specification for the propagator is “instant” updates, 
the architecture recommends that various techniques be used to delay the 
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updates; for example, updates can be batched. Connections can be cached, 
and the updates can be implemented in order of clearinghouse instead of 
time received. The propagator can also wait and see if a skulk is about to 
start. If so, there is no need to propagate the updates since the skulker will 
bring all replicas up to date. 


The Clearinghouse Background Process 


The clearinghouse background process runs periodically and is responsible 
for the following: 


° recovering clearinghouse resources from dead replicas 

° recovering clearinghouse resources from absent attribute values older 
than DSN$AllUpTo 

initiating skulks 

checking directory parent pointers and updating child pointers 
rebuilding the UpPointers set for the clearinghouse 

upgrading local replicas when new versions begin running 


Solicitation and Advertisement 


A name server will advertise its services under two circumstances. First, if 
the periodic advertisement timer expires. Second, if a solicitation message 
is received. When a solicitation is received, the name server checks to see 
whether the solicitation is local to the LAN or comes from the same DNA 
area. It then multicasts the answer to either the LAN or the whole area. 
Note that replies to solicitations are subject to a jitter adjustment to prevent 
synchronized multicasts. 

The following are the timers specified for advertisement in the naming 
service: 


Root Nonroot 
Clearinghouse Clearinghouse 
Distance (minutes) (minutes) 
LAN 5 5 
To area 10 10 
To whole net 20 never 


Note that advertisements to the area or the whole network need a multicast 
capability. In the case of Phase V, we have no WAN multicast. 


Security in the Naming Service 


Security in the name server is provided in two ways. First, there are an 
access control provision and internal consistency guarantees to prevent the 
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unauthorized disclosure, introduction, modification, or destruction of 
names. Second, the name server is an integral part of any authentication 
service. The authentication service is a set of attributes that are part of 
object names. In version 2 (current version) DNS uses authentication based 
on either passwords or proxy logins. 

Access control is provided by the name server. In DNS, security is placed 
in the hands of the object owners. This is discretionary access control. A 
service that DNS does not provide is nondiscretionary—centralized deci- 
sions through a security officer. In DNS, it is up to each object owner. 

Discretionary controls are provided through an access control set. The 
access control set (ACS) attribute is applied to every object entry, directory 
entry, soft link, and clearinghouse. An access control set is made up of a 
set of access control entries. The entries consist of a name (person) and 
access rights. The name can be an individual or a group; the group may in 
turn contain other groups. 

To process security, each name server includes a reference monitor func- 
tion. The reference monitor takes into consideration four pieces of infor- 
mation: 


° the ACS of the referenced object 

* the name of the principal requesting access 

¢ whether the principal was authenticated 

° the operation the principal wants to perform 


Access Control Sets 
An access control entry has three fields (see Fig. 5-16): 


° principal 
° options 
* access rights 


The principal is one of three names. First, it can be an individual user 
name, which is represented as a DNS full name. Second, it can be an im- 
plicit group, represented as a wildcarded full name. Third, it can be an 
explicit group. 

The first flag in the options field contains an indication if the principal 
name is really a group. The second flag is the default flag: If this particular 
object is a directory, the default flag indicates that this particular ACE 
should be propagated to the ACS of any child created. Note that when the 
ACE is replicated in the child entry, the default flag is not set on that entry. 
A third flag is the nopropagate flag. It indicates that the ACE should not be 
inserted in a child directory. Otherwise, the default is to propagate. The 
fourth flag is the unauthenticated flag which lets the reference monitor at- 
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Identifier 


tempt to match the requesting user to the principal field, even if that user 
has not been authenticated. 

The access rights for an ACE include read, write, delete, test, and control. 
The test access right allows the user to test a value but not necessarily read 
it, as in the case of comparing an incoming password with one stored in the 
clearinghouse. The control right allows the user to modify the access con- 
trol set. . 

To process the access control set, the access control entries are partitioned 
into individual, implicit groups, and explicit groups. Each one of these par- 
titions is processed separately, starting with the individual. 

The reference monitor takes the desired operation for the user and at- 
tempts to find permission in one of the access control entries. As soon as a 
match is found the reference monitor is given those rights. 

To blacklist a user, put the individual name in with a null rights list. 
Note that a blacklist does not work with a group since a user may be in 
many different groups. The reference monitor processes all groups until 
the desired rights are conferred or there are no ACEs left. 

Implicit groups are always processed before explicit groups. This is be- 
cause membership in an implicit group can always be determined locally: 
The group is a wildcarded name. An explicit group, on the other hand, 
may require network processing. Since the members of a group are full 
names, it is possible that a lookup on a member of a group will require a 
query to another clearinghouse. 


Creation and Propagation of Access Control Sets 


If the new entry is an object, the parent ACS is scanned for any access 
control entries with the default flag set. Those ACEs are copied into the 
child ACS but with the default flag turned off. If the new entry is a direc- 
tory, the parent is scanned for any access control entries without the no- 
propagate flag. Next, go to the ACS in the new entry and look for an ACE 
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containing the principal that created the object. This object, if present, if 
modified to full rights; you can always control your own object. Note that if 
the principal is not authenticated, the noauthenticate flag is set. If the ACE 
does not exist for the principal, it is created. 


Other Reference Information 


Figure 5-17 shows some architectural definitions in the current version (ver- 
sion 2) of the naming service. Figure 5-18 shows the possible errors re- 
turned by the naming service interface. 


X.500 


X.500 is the CCITT equivalent of ISO standard 9594. The CCITT and ISO 
versions are nearly identical. X.500 is used to communicate information 
between, with, or about objects. These objects can be application entities, 
people, terminals, distribution lists, or any other OSI or user-defined ob- 
jects. Note that X.500 is not a general-purpose relational DBMS. Conver- 
gence over time for updates is acceptable. An implementation that favors 
queries over updates is also acceptable. 

X.500 does not give different answers based on the location of the user. 
In this sense, it would not be appropriate to use X.500 as a means for get- 
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Function cannot be performed at this time 
No response from target resource 
Access Violation Caller does not have access rights 


Cannot Authenticate eer 4 uthentication failed 







NmaeoutNot.Donk Operation did not complete in time allotted 
and no modifications were made 
Timeout Maybe Done Timeout, but modifications may have been 
made to namespace 


Conflicting F A 

Entry Exists Creation of entry not possible 
Unknown Entry Entry does not exist in namespace 
Not Implemented Optional function not available 


Invalide Update Attribute cannot be directly modified 


= Sie et 


Clearinghouse 


Not A Replica 17 Clearinghouse does not have replica of this 
directory 
18 
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[Already Replica [18 | Clearinghouse has a replica of this directory __ 
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Description | 


Skulk in progress encountered a newer skulk | 
in progress and aborted 

Access violation encountered by a 
clearinghouse accessing another 
clearinghouse on behalf of a client 
Attempt to add replica of a directory on a 
clearinghouse running an older version of 
the naming service | 


tion in it | 

Wrong State 102 Entity cannot perform the operation in its 
current state | 

: the | 

Bad Nickname Proposed nickname already in use by anothe | 
name space 

















| Untrusted 
| Clearinghouse 








i t 
Not Root 105 Operation must be performed at the roo 

master replica of the namespace 

| Not Clearinghouse May not store a clearinghouse in this 

= 106 ; 

| Directory directory 

: RESuLost 107 Connectivity with the root of the namespace 
may have been lost 
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ting routing or other directional information. With the exception of access 
rights and unpropagated updates, a query will always give the same answer 
regardless of location. 

The basic distributed database, the Directory Information Base, consists 
of a series of objects. Objects have attributes and attribute values. The ob- 
jects are arranged in a tree, known as the Directory Information Tree (DIT) 
(see Fig. 5-19). 

As in the case of the Digital Naming Service, a full name can be derived 
from an object’s location in the tree. In X.500, this full name is known as a 
distinguished name (distinguished referring to the name’s uniqueness and 
not to the social status of the object). Also analogous to the Digital Naming 
Service is the alias entry, equivalent to the DNS soft link. 

To keep the directory consistent, there is a schema for the directory. The 
schema defines constraints on the directory usage, such as constraining at- 
tribute values to a certain range for an attribute type. Other schema entries 
constrain the types of attributes an object class can have. 

A variety of important considerations are not covered in the 1988 version 
of the directory. Specifically, ways to replicate the directory information 
base are not considered. Additionally, management of the schema, access 
control, and knowledge information are not covered. 
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X.500 allows the directory system agent to deny service based on a variety 
of considerations, including the 


* amount of time a search would take 
° size of the results 

° scope of the search 

° priority of the request 


It is also possible for the DSA to require validation, such as a digital signa- 
ture, on a request. 
The basic directory search operations include 


° read one or more attributes of an entry 

* compare a supplied value with an attribute value 

° list the immediate subordinates of an object 

* search the directory information tree for objects that satisfy some filter 
¢ abandon an outstanding interrogation 


It is also possible to modify the directory by adding, removing, or modi- 
fying an entry. The user can also modify a relative distinguished name. 

The directory is divided into directory management domains. At the top 
of the tree are public domains, known as administration directory manage- 
ment domains. At the bottom of the tree are privately run directory man- 
agement domains (DMDs). A DMD consists of at least one directory system 
agent and zero or more directory user agents. 


X.500 Components 


The X.500 architecture specifies two components. The directory user agent 
(DUA) is equivalent to the DNS clerk. The directory system agent (DSA) is 
the equivalent to the name server in DNS (see Fig. 5-20). 

The outcome of a request by the DUA can be a result, an error, or a 
referral. Referrals direct the DUA to another DSA. The DUA can specify 
either chaining, where the DUA contacts another DUA on behalf of the user, 
or referrals where the DSA retains control of the search but requests a hint 
from the DSA. It is possible that the DSA will refuse to chain the request, 
thereby returning an error message (and presumably a referral). 

The interaction between the DUA and the DSA is not really specified in 
the X.500 standards. It is possible that a DUA will always interact with the 
“home” DSA. A more sophisticated DUA might have several queries out- 
standing to different DSAs. 

The two protocols defined in X.500 are the Directory Access Protocol 
(DAP) and the Directory System Protocol (DSP). DAP is used for user agents 
to communicate with system agents. The system protocol is used with sys- 
tem agents. Both protocols are built on top of the Remote Operations 
(ROSE) protocols defined in X.219. 
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Several patterns of usage are envisioned for X.500. The basic operation is 
the lookup: Given a name, an alias, or the value of an attribute, read the 
values of other attributes. Other patterns might be browsing the directory 
(subject to access control) or a yellow pages application. A yellow pages 
application would be a filter based on some attribute, such as the business 
category attribute defined in X.520. Another pattern of operations would be 
a group validation which would answer questions such as “Is a particular 
user in a group?” and “Who are the members of a distribution list?” Fi- 
nally, X.500 might be used for authentication. The directory could hold 
passwords, public key certificates, digital signatures, or other forms of 
authentication information. 


Directory Schema 
The directory schema contains four types of information: 


¢ Directory Information Tree (DIT) structure 
° object class definitions 

° attribute type definitions 

° attribute syntax definitions 
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The DIT structure rules identify which objects may be subobjects of a par- 
ticular object. In other words, this part of the schema defines the valid 
subordinate and superior classes for an object. The object class definitions 
identify what the mandatory and optional attributes are for a particular 
object. It also identifies if an object is a subclass of another object. Two 
special object classes are top (at the top of the tree) and alias. 

The attribute syntax rules use ASN.1 data type definitions (see Fig. 5-21). 
It also allows the specification of matching rules for values, based on equal- 
ity, substrings, or ordering. An example of an ordering rule is that the 
value must be greater than zero. 

Not all names are required to be user friendly, since not all names will be 
used directly by the user. If they are however, the names should be de- 
signed so a person can guess the name. To design a name that can be 
guessed, several rules are specified in the X.500 standards. One of the most 
important naming rules is to avoid imposing artificial constraints to re- 
move natural ambiguities. An example is a common last name. Instead of 
changing a common last name to Smith2 (hard to guess), use another attrib- 
ute (such as location) to distinguish common names. For example, use 
“John Smith in Chicago” or “John Smith in Marketing.” In addition, a good 
user interface should be able to handle common abbreviations and vari- 
ations in spelling. This of course requires an X.500 implementation intelli- 
gent enough to vary the queries. 

Figure 5-22 shows how the attribute types can be organized into a direc- 
tory information tree. Countries, localities, and organizations are at the 
root of the tree. Either localities or organizations will eventually point to a 
name or a group of names. It is also possible to have organizational people 
(e.g., a vice president), devices (a computer), or a program (i.e., the directory 
itself) as part of an organization. 


Access Control in X.500 


Access control is a matter outside of the X.500 standard, but some guide- 
lines are provided. First, access control can be provided at different levels: 


° the entire tree 

° an individual object 

° an attribute 

* a select instance of an attribute value 


For a particular level, different access categories are defined, including de- 


.tect, compare, read, modify, add/delete attributes, and add/change object 
names. 


Each service request has a set of common arguments: 
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* service controls (empty as default) 

* security parameters (empty as default) 
* requestor name (optional) 

* aliased RDNs 

* extensions 

* operation progress 


The operation progress record is used when a DSA must resubmit a query 
to another DUA. The aliased RDN indicator is used much like the DNS 
progress record to show the resolution of aliases. 

Service controls are used by the DSA to control the type of search that 
will be carried out on the user’s behalf. These controls include: 


° prefer chaining 

¢ chaining prohibited 

* local scope only 

¢ do not use copied information 
¢ do not dereference aliases 
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° priority (low, medium, high) 

* time limit for the search 

* size limit for results 

* scope of referral (limited to the management domain or to the country) 


In addition to service controls, a search request will also add an entry 
information selection that specifies all attributes, one attribute, or selected 
attributes, plus the desired name and a filter. Filters are based on a particu- 
lar attribute value, matching on equality, a substring, whether value is pre- 
sent, or an approximate match (based on a locally defined algorithm such 
as soundex). 
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Resolving requests 
There are three ways to get information: 


° chaining 
° multicasting 
° referrals 


Multicasting is a special form of chaining where we can send the same re- 
quest to several places. A referral contains a knowledge reference, which is 
an indication of which DSA might be able to resolve a particular request. 

When a DSA cannot resolve a request, it will usually chain, unless the 
request said do not chain or there is some administrative reason not to 
chain. If the DSA cannot chain, it will provide a referral. 

Every entry in the DIB is administered by a single DSA. There is no 
reason, however, why other DSAs cannot make a copy of the entry and 
cache it. It is possible for the DUA to specify that copies are not to be used. 
The answer to a query will specify if it is from a copy. The specific meth- 
ods used to control caching and replication are not defined in X.500: There 
are no equivalents to the skulking and update policies of the naming serv- 
ice. : 

A particular DSA has two kinds of information: directory information 
and knowledge information. Knowledge information resolves the naming 
context information held by a particular DSA. A part of the tree is known 
as a naming context. The context has a context prefix (the tree from the 
root to the beginning of the context). A naming context is the context prefix 
and a collection of knowledge references. 

You need to keep at least the superior references, internal references, and 
subordinate references. It is possible you will also keep nonsubordinate 
references (known as cross-references). The first-level DSAs (those near the 
root) are responsible for knowing about all other first-level DSAs. The 
lower-level DSAs need to have a reference to the path to the first-level DSA. 


Security 


X.509 defines an authentication method based on the public key cryptosys- 
tem developed by Rivest, Shamir, and Adleman. (Technically, X.509 puts the 
RSA cryptosystem into an appendix, but it is widely accepted as the method 
to provide authentication services). 

The X.509 standard defines four types of information: 


e authentication information held by the directory 

* how to get authentication information 

* how the information is formed and placed in the directory 
° three ways applications might use this information 
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Authentication comes in two forms. The simple, or weak, authentication 
is a simple password exchange. Password-based exchanges are subject to 
human-engineering problems: People are somehow tricked into giving away 
their password, or somebody observes the password on the network. A 
more advanced form of authentication is cryptographically formed creden- 
tials, known as strong authentication. Credentials are formed offline, then 
placed in the directory. The X.509 standard uses RSA technology as an 
example of a public key method. Other public key methods could also be 
used. 

For a strong authentication method, each user has three attributes: 


* a unique name 
¢ a secret key 
* a public key 


The goal is to find out if the user really has the secret key, given a name 
and public key. 

To get a user’s public key, you must first have the public key of the certi- 
fication authority (CA). When you communicate with the CA it produces a 
certificate. To open the certificate, we use the public key of the CA. Hidden 
inside that certificate is the public key of the user. If the service provider 
has the CA’s public key, the public key of the user can be found. 

A certificate is based on the following: 


¢ the user’s full name 

¢ the user’s public key 

* a certificate serial number 

¢ an identifier of the algorithm used 
¢ the time validity of the certificate 


The certification authority maintains a variety of different kinds of cer- 
tificates: 


¢ Forward certificates are the keys of this CA as encoded by other certifi- 
cation authorities. 

* Reverse certificates are the keys of other CAs as encoded by others. 

° Certificates for users. 


The forward and reverse certificates allow a certification path to be set up. 
In this case, you can eventually get the public key for a user maintained by 
another CA. 

Once the public key of a user is obtained, we attempt to authenticate it: 
The user sends a digital signature, encrypted with the user’s digital signa- 
ture. A one-way hash (decryption) algorithm is applied to the digital signa- 
ture, then compared to the results obtained using the public key of the 
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a 
user. If the results match, the user had the proper secret key and is pre- 
sumed to be the valid user. 

How the key data are generated is an issue beyond the scope of the X.509 
standard. A user might generate his or her own key pair, or a CA might 
generate it. Things like smart cards are a possible repository for the key 


pair. The smart card would itself be secured by a Personal Identification 
Number (PIN). 


DASS 


DASS is Digital’s distributed authentication security service. DASS is based 
on public key technology, and has three components: 


° key generation 
* a certification authority 
* authentication routines 


DASS is part of a longer-range program from Digital known as the Digital 
Distributed System Security Architecture (DSSA). The architecture covers: 


* user and system authentication 

* mandatory and discretionary security 
* secure initialization and loading 

* delegation of authority 


The security architecture is not meant to address top-secret, multilevel 
security requirements in the military. It instead addresses commercial 
grade requirements. The architecture makes extensive use of encryption. 


Summary 


The DNA Naming Service is a key component of DECnet/OSI Phase V. The 
naming service is a replicated, distributed database with a loose consistency 
guarantee. 

A prime user is the DNA Session Control layer, which uses the naming 
service to resolve full names into the network address or tower set of the 
node. Other naming service users are electronic mail systems, security sys- 
tems, and remote procedure call mechanisms. 

DNS is a primitive naming service which takes a full name and resolves 
it into one or more attributes. X.500 is a descriptive service which starts 
with a few attributes and returns one or more names. DNS could be used 
to form the infrastructure for a descriptive name service. 

Security is integrally linked with naming services. Public key cryptogra- 
phy systems use the naming service as a repository for public keys. Making 
the public keys generally available allows a user to engage in authenticated 
communications with a wide user base. 
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Support Protocols 








support Protocols 


The DNA Naming Service is one thing that distinguishes the DNA side of 
the protocol stack from the OSI side. As we saw, the Digital naming service, 
which provides a distributed, replicated, primitive service, offers a service 
significantly different from X.500. 

Digital calls this strategy “adding value” to international standards. 
Rather than wait for a complete standard, Digital goes ahead and develops 
its own proprietary standards. The naming service is one example, but we 
will see several others such as the Local Area Transport protocols, and their 
network management strategy. 

There can be no argument that many of these services are valuable in a 
network. Purists maintain that using proprietary protocols violates the 
spirit of open systems and OSI. Digital marketing managers maintain that 
they are simply filling in holes until the international standards mature. In 
some cases, particularly the naming service, Digital has used other forums 
such as the Open Software Foundation to try and make their approach ac- 
ceptable to a wider audience. 

Whatever the merits of the two points of view, we see that there are a 
number of such holes Digital has filled. These supplementary protocols op- 
erate only on the DNA side of the protocol stack, further distinguishing the 
Digital-to-Digital functionality in the network from the services available in 
a truly heterogeneous environment. Needless to say, this gives Digital sales- 
people features to sell that their competition does not have. On the other 
hand, salespeople from other companies can argue that taking advantage of 
the added functionality locks the customer into Digital. They are probably 
both right. 

In this chapter we look at three sets of supplementary protocols. First, 
we look at the time service. The time service allows many different com- 
puters to synchronize their clocks within a degree of precision and error 
factors. We saw in Chapter 5 that the naming service skulk process de- 
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pends heavily on an accurate update time stamp to coordinate distributed 
updates. We will see other instances in which an accurate clock is vital. 

Next, we look at the remote procedure call (RPC) mechanism. As part of 
the Open Software Foundation, Digital has adopted the Hewlett- 
Packard/Apollo RPC protocols as a way of telling remote computers to per- 
form a particular task. The RPC performs functions equivalent to the OSI 
presentation layer and the OSI Remote Operations Service (ROSE). 

Finally, we look at a specialized, low-level protocol called the Mainte- 
nance Operations Protocol (MOP). MOP, a direct user of the data link, ex- 
tends a system’s console across a data link. This simple task is actually 
quite powerful, allowing a node to boot across the network. Specialized 
gateways and servers, as well as diskless workstations, all use MOP as the 
way of obtaining their operating system from another node. 

The time service, the naming service, and the remote procedure call all 
operate at either the Session Control layer or as direct clients of the data 
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link layer (see Fig. 6-1). Being a direct client of the data link layer makes 
sense for two nodes on a local Ethernet, which do not need the extra over- 
head of routing or other upper-layer functions. 

In a wide-area environment, or one with multiple subnetworks, it does 
not make sense to bypass the upper-layer functions. Routing, transport 
level reassembly and error recovery, and sessions all become valuable func- 
tions in a WAN environment. In this case, services like RPC and the time 
protocol are able to establish a DECnet session for communication. Note 
that none of these services uses the OSI session layer, making these services 
unavailable to native OSI applications. 

MOP is different in that it does not use the Session Control layer. MOP is 
an extremely primitive protocol, intended to be simple enough to be imple- 
mented in Read-Only Memory (ROM) in a processor. When a diskless node 
initializes, it is ranning the MOP protocols and broadcasts an appeal for 
help. Another node will respond and force-feed it the operating system. 
Until the operating system is resident, the node is not really running DEC- 
net, but only the MOP component. 


Need for Synchronized Time 


On one computer, an inaccurate clock is not really a problem. All users get 
the same inaccurate reading, and the temporal ordering of their operations 
is maintained—an operation performed before another gets an earlier time 
stamp. In a network, it is quite possible that clocks have different readings. 
If a database such as the Naming Service, is being updated by two different 
users, an accurate update time is vital. 

When two clocks have different readings, it known as skew. Im all prob- 
ability, both times are wrong. The difference between two local clocks is 
skew, whereas the difference between a clock and “correct” time is an inac- 
curacy. 

Correct time is measured with respect to Universal Coordinated Time 
(UTC), which is maintained by the BIH (International Time Bureau). From 
UTC, we can derive political derivations such as Pacific Standard time. We 
can represent a political derivation as the UTC plus a Time Differential Fac- 
tor (TDF). 

There are two other factors, aside from skew and inaccuracy, that can 
affect the representation of time. One is drift, which is an increasing inac- 
curacy of a clock over time. The other is resolution, the ability of a clock to 
measure time in increasingly granular chunks. 

At the level of a computer clock, measuring time in microseconds or mil- 
liseconds, it is unlikely we will have perfectly accurate time. The clock will 
be inaccurate, will be skewed with respect to other clocks, will drift, and 
will probably not have enough resolution to time stamp all operations oc- 
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6-2 Time Protocol 


curring on a processor. The time service, within the constraints of inaccu- 
racy and other problems, attempts to provide the best possible repre- 
sentation of time in a distributed computing environment. Typically, some 
computer (or computers) on the network has a time provider—a clock that 
is considered accurate (see Fig. 6-2). That provider can be an automatic link 
to UTC, or can be set by management. Setting a clock by management 
(known as the “wristwatch protocol”) will not provide the accuracy of an 
automatic link. 

The time protocol is a way of taking the time provider’s information and 
distributing it to the rest of the network. The process that makes the infor- 
mation available is a time server. It is possible that a time server does not 
have a direct time provider and instead uses a courier protocol to get and 
adjust another computer’s time. Figure 6-3 shows a typical network con- 
figuration. As with the naming service, we have servers and clerks. Typi- 
cally, every node will have a clerk component. A few computers will be 
considered to be servers. 

If there are enough computers on the same LAN, clerks will use data- 
gram-based services to retrieve the time from each of the servers. The un- 
ion of these times will become the local version of time. If there are not 
enough local servers available, a node can use the global servers, using the 
Session Control layer to set up a virtual circuit. Once again, several differ- 
ent servers are consulted by the clerk to derive a union of time. 
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6-3 Time Service Network Configuration 


The courier in Figure 6-3 is a local server that makes use of the global 
server as a time provider. In any case, sets of servers always try to synchro- 
nize their clocks with each other on a periodic basis. 

Deciding what the time is on a server is not necessarily an easy matter. 
If we could get an instant reading it would be no problem, but the network 
introduces propagation delay, and individual nodes take time to process 
network packets. Figure 6-4 shows the process a node goes through to find 
the time from another node. First, the clerk reads the local clock and pre- 
pares a request to go on the network. That request has a preparation delay 
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and once sent, a propagation delay. At the server, the packet is again de 
layed while it is decoded. Once the packet reaches the time service, the 
server makes note of what time the packet arrived. At this point, there may 
be an additional delay, so the server waits until the response is just about 
ready to send and makes another note of the time. 

Once again, the packet has a sending delay and a propagation delay on 
the network. Once received back at the clerk, there is a further delay while 
the packet is copied into buffers and decoded by lower layers. When the 
clerk gets the packet, it once again takes note of the time. 

The problem for the clerk is to find out what the time really was (at least 
according to this one server) when the original packet was sent out. The 
bottom of Figure 6-4 shows the formula to decide what the time really was 
when the packet was sent and thus by how much the local clock should be 
adjusted. 

In addition to the “real” time, the clerk maintains an error factor. In- 
stead of a point in time, we represent time as a range. By consulting sev- 
eral servers, the clerk takes the union of these different times to represent 
the local time. The formula used in the Digital time service can throw out 
one of the server’s responses if they are too far out of the range. 

To find a server, most nodes wait for a time server advertisement (see 
Fig. 6-5). The advertisement, sent out periodically, includes the network ID 
of the server and the role as a courier. The courier role indicates whether 
the node is a courier and, if so, whether it is the active or backup courier 
for a local set of servers. The message then includes the data link and net- 
work IDs of any other servers known at the time. 

If there is no advertisement before a clerk needs the information, the 
clerk can multicast a solicit servers request (see Fig. 6-6), which generates a 
response similar to the advertisement (see Fig. 6-7). Notice that all of these 
messages include 4 bytes of version information, allowing graceful updates 
to the time protocol in the future. A clerk can find out which versions of 
the protocol a particular server supports (see Fig. 6-8). 

Advertisements and requests are multicast only within the breadth of a 
subnetwork. To find out global servers, a node would use the DNA Naming 
Service. The naming service would return the network address of any 
global servers. A node that is not on a broadcast-type subnetwork (e.g., Eth- 
ernet) would use the naming service as a way of finding the location of 
servers. 

The actual time request and response messages are shown in Figures 6-9 
and 6-10. The request is simple, including a message ID as a way of corre- 
lating incoming responses. The response includes the server time (when 
the packet was first read) and the processing delay (when the response was 
sent back out). 
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6-10 
| Goue ination Message 


The time response message also includes an epoch. As with the naming 
service, the epoch is used to allow groups of servers to coordinate their 
activities. In the time service, the epoch allows several different domains of 
time to run concurrently. Over time, the different domains are gradually 
merged into a unified time domain. 


Unique Identifications 


A time stamp is a way of identifying an operation uniquely over time. It 
does not, however, uniquely identify an operation over space—the union of 
possible computers on the network. For many operations, both a time 
stamp and a unique ID are necessary. 

The unique ID is unique across both time and space. Note that a time 
stamp is also needed. Although the current version of the Digital unique ID 
architecture preserves temporal ordering (because it incorporates a time 
stamp), there is no guarantee this will hold in the future. The unique ID 
architecture document cautions developers that in the future there may be 
large random numbers used for unique IDs. 

A unique ID consists of the following pieces of information: 


¢ 48-bit system ID 
° UTC 
° UTC Specifier to allow multiple UIDs to be generated in one clock tick 
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¢ clock sequence value (to guard against a nonmonotonic resetting of 
clock value) ; 
* version number for UID architecture 


The unique ID has a total size of 128 bits. This unique ID from Digital is 
basically interoperable with the UUID used in the Hewlett-Packard/Apollo 
Network Computing Services. This interoperability is important because 
the remote procedure call mechanism may operate in both DECnet and 
Hewlett-Packard/Apollo networking environments. 


Remote Procedure Calls 


In a single-machine environment, programs are structured as a set of proce- 
dures (see Fig. 6-11). A procedure calls another, passing in some arguments 
and receiving back some information. The information received back can 
be a simple status indicator that the procedure executed properly or could 
be complex information as in the case of a database query. 

A remote procedure call mechanism extends this paradigm to work in a 
network-based environment (see Fig. 6-12). The trick is to furnish a pro- 
gram on the local computer that emulates the called procedure. This pro- 
gram, called the client stub, masks the network-resident aspects of the 
communication from the main program. A client stub, using network calls, 
will communicate the call to a server on the network, sending in the argu- 
ments. The called procedure, like the calling procedure, should be unaware 
of the network operations and uses a server stub that emulates the calling 
procedure. 

This simple paradigm allows program developers to concentrate on the 
functionality of their programs, then later deploy their programs in a dis- 
tributed network of clients and servers. A well-developed remote procedure 
mechanism works on numerous computing platforms and over a variety of 
networks. 

Digital has chosen the Hewlett-Packard/Apollo RPC mechanism as the ba- 
sis for DECnet remote procedure calls. The Hewlett-Packard mechanism 
was extended in cooperation with Digital to support DECnet and the DNA 
Naming Service. In addition, the Digital implementation uses the Digital 
multithread architecture, which allows a single server process to keep mul- 
tiple threads of execution going, one for each of the requesting procedures. 

Most of the protocols examined in this book, such as LAT, the name serv- 
er, and network management, use a remote operations method of clients 
communicating requests to servers. All of these different protocols have in 
effect implemented their own remote procedure call mechanisms. It is 
likely that all of these protocols will eventually migrate to the common RPC 
platform. 
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The RPC mechanism handles many tasks that are handled in the OSI 
environment by the presentation layer. The RPC bind message (see Fig. 
6-13) sets up an association between a client and a server. The main work 
being done in this bind message is to specify how data are to be repre- 
sented. 

In the RPC mechanism, an interface is a set of operations packaged to- 
gether. The interface is uniquely identified by a UID (Known as a UUID in 
the Hewlett-Packard terminology). The interface, in addition to operation 
definitions, includes a definition of how data are to be represented. The 
RPC bind message takes each of these data representations (known as ab- 
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stract syntaxes) and assigns one or more transfer syntaxes to it for the pur- 
pose of transmitting information on the network. 

In addition to the data representation, the bind message has two other 
sections: authentication and flags for different operation methods. The 
authentication is not actually specified in the RPC mechanism. Various 
types of authentication can be supported and it is up to the client and the 
server to support a particular kind mutually. As Digital moves toward pub- 
lic key-based authentication, we can expect that to be one of the types sup- 
ported. 

The flags allow a bind message to have multiple fragments, which is use- 
ful in a LAN-based environment. For a virtual circuit interface, the frag- 
mentation is not necessary since the session and lower layers take care of 
fragmentation and reassembly of messages. 

The pending alert flag is used when a client has multiple threads of exe- 
cution, all talking to a server. A particular thread may be blocked because 
it is waiting for the server to complete. Another thread, when sending a 
message, sets the pending alert flag to notify the server it is blocking execu- 
tion. Presumably, the well-behaved server will do something to move the 
blocked thread forward. The asynchronous alerts flag indicates whether 
status messages are desired. 

The authentication flags provide optional hooks for authentication, mes- 
sage integrity, and privacy services. The actual values for all three types of 
integrity mechanisms are not specified in the RPC architecture but depend 
on the underlying network environment. For example, Digital uses a 
“weak” (password-based) authentication scheme at the session layer. The 
RPC mechanism would use that. 

The “did not execute” flag is only meaningful on an error (fault) message. 
This flag indicates there is a guarantee the indicated call did not execute. 
Otherwise, there is a possibility that the call did execute, and the client is 
responsible for figuring out what really happened. 

The last flag indicates that maybe call semantics are requested. Nor- 
mally, a call is explicitly acknowledged by the server. With maybe seman- 
tics, the server does not have to acknowledge the request, and there is no 
guarantee the server has received the packet. 

Figure 6-14 shows the bind accept message. As with the bind request, the 
flags are present. A body data representation label enables the client to 
read the rest of the packet. The accept message includes a maximum re 
ceive and transmit size for requests and responses. It also includes a secon- 
dary address. When a server receives a request, it may start up a new 
process to handle this particular set of calls. 

For each of the contexts specified in the bind request, the accept message 
also includes which transfer syntax was chosen. Finally, there is an inter- 
face hint. The meaning of the hint is up to the server, and the hint is 
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provided to allow a server to identify the meaning of a particular call 
quickly. A typical use of a hint is a handle—a pairing of a server process 
and a particular remote user. 

The packet also allows an authentication trailer. This trailer, as in a bind 
request message, is optional. Figure 6-15 shows that a third leg is also possi- 
ble for the authentication process. Again, it is up to the underlying net- 
work to provide an authentication model to be used by the RPC 
mechanism. 

The bind request and bind accept messages have a variant, known as 
alter context messages. These messages allow a particular client and server 
to switch the interface they are using. For example, the association may 
start out using a database interface—a series of operations supporting dif- 
ferent SQL calls. The association may wish to switch after that to an elec- 
tronic mail interface supporting the transmission and posting of messages. 

Instead of a bind accept message, it is possible that the server may send 
back a bind reject (see Fig. 6-16). Note that the bind reject, like all messages, 
has an optional authentication trailer. In a high-security environment, it 
may be necessary to authenticate every message to prevent some other 
node from masquerading as the target of a call. 

The reject message includes a’ variety of reasons for rejecting a bind; for 
example, the server could be too busy to service the call. It is possible that 
authentication failed, in which case the well-designed server returns “not 
specified” as the reason for the reject. 

Figures 6-17 and 6-18 show the format of the RPC request and response. 
Notice that the request keeps a pending alert count to notify the server how 
many alerts it has outstanding. It also includes an allocation hint, useful in 
telling the other side of a dialogue how much space a particular operation 
might take. The message also has a call identifier, which will be used to 
identify the incoming response. Remember that a client may have several 
calls outstanding at once. The particular operation needed is specified by 
interface and object UIDs plus any data passed in by the stub. 

The response contains the call identifier plus the returned data. It also 
includes a runtime fault code, equivalent to a return status message in a 
single-machine environment. 

In addition to the request and response messages, there is a wide variety 
of status messages (see Fig. 6-19). A client can “ping” a server to find out 
the status of a particular message. There are also explicit acknowledgments 
available for responses and quit messages. Finally, there are the working 
and no call answers to the ping message used by the server to indicate the 
current status of a call. 

This discussion of the RPC mechanism is a brief introduction to a com- 
plex subject. In addition to the Hewlett-Packard/Apollo mechanism, there is 
another model used by Sun Microsystems and Netwise that forms the basis 
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for the Open Network Computing model (ONC), Novell networks, and sev- 
eral other environments. 


Maintenance Operations Protocol 


The maintenance operations protocol is a direct user of the data link. Typi- 
cally, MOP uses the Ethernet data link, but it can also work over point-to- 
point links such as HDLC or DDCMP (typically running in maintenance 
mode). MOP provides three levels of functionality: 


¢ tests the communications link 
* acts as a remote console 
* uploads and downloads to remote system memory 


The main use of MOP is as a remote booting protocol, but it is also used by 
network management products as a way of managing remote systems. 

The three functions operate in increasing levels of complexity: One has to 
be operating before the next will operate successfully. The system console 
function allows low-level control of a system across the subnetwork. The 
manager can perform the following functions: 


° identify the processor 
e read data link counters 
©® issue a boot command 


Note that this is not a secure protocol: it is extremely low level. There is an 
ID parameter, but it just prevents a system from receiving the wrong oper- 
ating system. Presumably, if security is an issue, data link encryption 
would be used. 
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Figure 6-20 shows a summary of MOP messages. The loop message al- 
lows the MOP module to test the link by performing a loopback operation. 
The read counters message returns the counters being kept by the underly- 
ing data link. 

After the low-level loop and counters messages, we see the console com- 
mands. These two messages allow a remote process to submit commands 
as if they were on the local console of a device. Many operations, such as 
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the boot command, must be done on the console of a device. The console 
commands thus form the basis for other operations such as remote booting. 

Next is the console reservation command, allowing a network manage- 
ment device to “reserve” the console for future use. The same message has 
a release option. Notice the verification code—this is a password-like 
mechanism. It does not provide security, but is used so a node does not 
mistakenly attach itself to the wrong remote console. 

The remote ID message allows a manager to identify a remote operation. 
Different parameters can be used to identify which version of MOP and 
which functions are supported. Other options support things like reserva- 
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tion timers for reservation request and the types of systems and communi- 
cation devices being used. 

Figure 6-21 shows an example of the remote ID message. The message 
shows that version 3 of MOP is being used and many of the MOP functions 
are not supported. It does allow a node to attach itself as the console, but 
this particular implementation does not support booting other nodes on the 
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network. The message also includes a hardware address and the type of 
communication device being used. 

One special type of console command is the boot command. This mes- 
sage tells a remote node to reboot itself. It indicates which management 
(CMIP) scripts to use during the boot process and whether to boot in nor- 
mal or maintenance mode. It also allows the requestor to furnish the oper- 
ating system to be used during the boot process. 

A boot command is one way to specify that a boot operation should be 
done. Another way is to do it when a node initializes. At that time, the 
node will broadcast an appeal for help. A node on the subnetwork will 
then volunteer assistance. 

The actual boot process consists of loading into memory at the requesting 
node. Another version of this is to have a node dump data from memory 
used for diagnostics. Next, we have the memory load message, indicating 
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the node is ready to accept data. The data message is used to transfer 
loaded data into memory. 

To specify what information is needed, the request program message is 
used. Typically, the remote booting process starts with a very primitive 
primary loader. This program then loads the secondary loader, followed by 
a tertiary loader. At this point, the node is almost operational and loads the 
operating system in. Instead of loading the normal operating system, it is 
possible to load a management image. The CMIP script, the network man- 
agement initialization script, is used to set network management parame- 
ters such as maximum data packet sizes or retransmission timers. 

As with other DNA modules, MOP keeps a variety of different kinds of 
management information. Figure 6-22 shows the kinds of information 
kept. For each MOP client, for example, the MOP module keeps informa- 
tion such as which circuit to use, the names of files to use, and any host 
names and addresses. 

For each circuit (subnetwork link), there are the name of the link, the 
retransmit timer, and a varieties of other counters. This information is pre- 
sented to show, as in the case of the chart of DDCMP management informa- 
tion, the variety of different counters and parameters available in the 
DECnet environment. The final chapter of this book on network manage- 
ment will show how this information is made available to the network 
manager. 
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LAT 


In previous chapters we examined three different network architectures. 
The two main architectures, DECnet and OSI, used a common infrastruc- 
ture up to the transport layer. At the session layer, they split into two sepa- 
rate architectures, each with its own applications. 

The third architecture was the Maintenance Operations Protocol. Al- 
though MOP is technically part of DECnet, it is a direct user of the data link 
layer and can operate without the rest of DECnet. An extremely simple 
protocol consisting of one layer and a set number of messages, MOP is used 
for downline loading an operating system from a remote node. 

In this chapter we examine two additional architectures. We will briefly 
look at the VAX Cluster, which is used to take a disk drive and make it 
available to multiple computers simultaneously while preserving the integ- 
rity of the data. 

We will devote the rest of the chapter to the Local Area Transport (LAT). 
LAT, like MOP a. direct user of the Ethernet, is a protocol intended for a 
terminal server or other workstation such as a PC to make use of the serv- 
ices of a host. 

Figure 7-1 shows a typical Digital configuration. Three workstations and 
two terminal servers, a work group, share a single Ethernet. A second Eth- 
ernet has several minicomputers acting as servers. The two Ethernets are 
bridged together to form a single extended LAN. 

On the backbone system we see three VAX minicomputers. The VAX sys- 
tems are also connected to a second type of network, the VAX Cluster. The 
VAX Cluster uses a 70 Mbps data link called the CI Bus to connect minicom- 
puters to Hierarchical Storage Controllers (HSC)—a specialized server for 
attaching disk drives. 

In addition to the CI Bus, the VAX Cluster protocols could be direct users 
of the Ethernet but at an order-of-magnitude slower speed. Digital is also 
enhancing the VAX cluster architecture to use FDDI-based backbones. No 
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matter what the subnetwork, the cluster architecture does the same thing— 
allows several minicomputers to share a single disk drive. 

The HSC controllers are each connected to two disk drives. The two disk 
drives are in turn dual ported to multiple controllers, providing fault toler- 
ance. The data are shadowed—that is, written simultaneously on two differ- 
ent disk drives in case of failures. 

A distributed lock manager running on the VAX systems is used to coor- 
dinate access to the data on the HSC controllers. The combination of re- 
mote access to data and the lock manager plus a few incidental services 
form the VAX Cluster. 

To the user, each of the different VAX systems looks the same—they all 
have the same data. Whether a workstation or a terminal user, it does not 
care which of the systems they log on. 

The purpose of LAT was originally to solve the problem of which of the 
cluster computers to log onto. Since they all provide the same data, the 
user only wants to log onto the computer that is providing the best service 
at the time. Needless to say, the question of trying to connect to many 
different hosts has a broader applicability than just to the VAX Cluster, al- 
lowing LAT to be used in many other situations besides clusters. 

LAT has since been extended to solve other problems. In addition to load 
balancing, LAT allows a single virtual circuit to be maintained between a 
terminal server and a host, multiplexing data from several users. This mul- 
tiplexing feature means less of the subnetwork bandwidth is being used. 

The multiplexing aspect of LAT makes it ideal as a platform for the X 
Windows System and X Windows terminals. An X Windows terminal is a 
device dedicated to providing X Windows services to the user. The operat- 
ing systems and applications all reside on servers on the network. 

X, by its nature, consists of many asynchronous events. Things like 
mouse movements, window resizing, and mouse clicks can happen at any 
time. The X terminal is responsible for packaging these events and sending 
them to the relevant application, which decides how to interpret the events. 

LAT allows several events to be packaged in a single packet and sent over 
the network, saving network bandwidth, as well as host processing power. 
If each event gets a separate packet, each packet generates a CPU interrupt. 
Combining the events allows the host to deal with them all at once. 

LAT assumes a LAN-like data link with a very low probability of prob- 
lems. Things like datagram duplication, excessive delay, bandwidth satura- 
tion, and misdelivery are low or very low probability events. Low 
probability is less than one per hour. Very low is less than one per a very 
long time (e.g., a year). 

LAT requires the following functionality of the data link: 


¢ IEEE 802.2 Type 1 operation 
° Multicasting capability 
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¢ Specification of source and destination addresses, protocol ID, or type 
indicator : 
e 48-bit addresses 


Examples of data links that meet these requirements are FDDI and 
CSMA/CD (Ethernet). Currently, only CSMA/CD is used for the LAT proto- 
cols (although FDDI may act as the backbone to bridge two Ethernets to- 
gether). 

LAT is an asymetric master-slave model. This makes the operation of the 
slave/host simple. LAT assumes an environment where it is a minor client 
of the LAN: The LAT throughput needed should be much less than the 
bandwidth of the LAN on which it runs. 

There are several important nongoals of LAT: 


* no general-purpose transport services 
° no security beyond what the LAN provides 
° fault-tolerance provided by the underlying LAN 


The last nongoal, fault-tolerance, is provided in a minimal respect. LAT al- 
lows the use of multiple LAN adapters (and hence multiple LANs). The LAT 
protocols will try alternative paths in the case of a failure. 

The basic characteristic of LAT is that it is timer based: Messages are ex- 
changed periodically based on the timer value. The second characteristic is 
that messages provide multiplexing: Data from multiple sessions can all 
share a single message. 

LAT divides functionality into masters and slaves. The typical implemen- 
tation, however, can support both master and slave operation. A terminal 
server, for example, is typically run in master mode—the user on the termi- 
nal wishes to use a program on a host. Occasionally, the host is the master, 
as when an application wishes to use a printer or modem on the terminal 
server. 

It is possible for a single port on a terminal server to be engaged in sev- 
eral simultaneous sessions. It is up to the particular implementation to de- 
cide how to interleave the data. Typically, the user has a hot-key to switch 
between sessions. The operative question is what happens to data that 
would have gone on the screen: is it buffered or lost? 

There are two main layers in LAT, with an additional sublayer (see Fig. 
7-2). The virtual circuit layer maintains a virtual circuit between a master 
and a slave. It provides the error-free sequential message streams found in 
other transport layer providers. The session layer is the data transport in- 
terface to the user. Its function is to multiplex one or more user sessions 
onto the underlying shared virtual circuits. 

In addition to the virtual circuit and session layers, there are two addi- 
tional services: the LAT directory service and the slot sublayer. The LAT 
directory service is responsible for managing service names and ratings. 
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7-2, LAT Component Structure 


Names are used to identify LAT resources. LAT provides a directory serv- 
ice that helps translate names to a particular entity (not to be confused with 
the separate DNA Naming Service in Chapter 5). LAT supports three types 
of named entities: 


* ports 
® nodes 
® services 


A rating is used by the session layer to balance the number of sessions 
across a set of nodes: If more than one node offers the same service, the 
session layer is able to pick the one with the best service rating at the time 
a session is initialized. 

This load balancing balances new sessions, not existing sessions. If we 
initialize a session on a node with a good rating and service subsequently 
degrades, LAT will not move to a better node. In addition, load balancing is 
not based on the amount of traffic going to each node; it is based on what- 
ever service rating is broadcast by a particular node. 

The LAT directory service operates in two modes: 


¢ In announcement mode the services and their ratings are periodically 
multicast. 
¢ In solicitation mode an explicit request/response polling is performed. 
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7-3 Levels of LAT Flow Control 


Announcements are used by masters to construct and update a local 
cache of services and their ratings. Solicitation is used when a user re 
quests a service not in the cache or when a node intializes. Solicitation may 
also be used by low-functionality implementations (slave only) that do not 
wish the burden of listening to periodic announcements. 


Flow Control in LAT 


The terminal user is a particularly slow user in comparison to other net- 
work components, hosts, and servers. Flow control is thus quite important 
in LAT to avoid large amounts of data from overflowing buffers or saturat- 
ing devices. Flow control in LAT is provided at several different levels (see 
Fig. 7-3). 

At the lowest level, the underlying Ethernet provides flow control among 
different users through the CSMA/CD protocols. Too many terminal serv- 
ers (or any device for that matter) causes excess collisions. As long as we 
have an appropriate number of nodes, the CSMA/CD protocols arbitrate use 
of the medium. 

The virtual circuit layer arbitrates the flow of data between two nodes. 
Windows and timers, identical to the TP4 and NSP transport layer func- 
tions, make sure the number of packets reaching a device do not over- 
whelm the buffers. 

At the session layer, we see the same token-like mechanism used in the 
OSI session layer. Here they are called credits. A user or program may 
only submit a slot of data when it has a credit. If an application is busy, it 
withholds credits from the user. 

At the highest level is the X/ON and X/OFF mechanism. If a user sees too 
much data, the user can hit the control/s sequence to freeze the screen. 
This will eventually fill the user’s buffers, which will cause the session layer 
to withhold further credits from its peer. 
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Virtual Circuit Layer 


The virtual circuit layer provides an interface to its user, the slot sublayer. 
It provides the following services: 


start-up and shutdown of circuits 

reports to the slot layer on circuit quality 

delivery of messages in sequence to the slot sublayer 

verification that messages are addressed to known circuits 

° pipelined transmission of messages or a ping-pong acknowledgment 
¢ optional caching of out-of-sequence received messages 


Pipelined transmission uses a window-based flow control method. The vir- 
tual circuit layer uses data link addresses provided by the LAT directory 
services. 

Normally, the virtual circuit component on the master sends messages to 
the slave based on a timer. The slave responds to the message with a mes- 
sage of its own. Under a few circumstances, it is possible for a slave to send 
unsolicited messages. 

Virtual circuit overhead is minimized because there is only one circuit 
for a particular master-slave pairing, instead of one for each application- 
user pairing. Further, messages are exchanged on a regular, periodic basis. 
Polling and frequent interrupts are both minimized. Another efficiency 
mechanism is that both virtual circuit control and user data can share a 
single message. 

The virtual circuit message is an eight-octet header consisting of the cir- 
cuit ID and sequencing information. This is followed by a series of slots. 
Each slot has a 4-byte slot header and data (see Fig. 7-4). 

We can see in the header that in addition to the sequence numbers (and 
piggybacked acknowledgment) there are several flags. The flags, in addi- 
tion to identifying the message type, indicate whether the master or the 
slave sent the message. The response requested flag, discussed in more de- 
tail later, indicates that a slave has more data to send and therefore wants 
the master to send it another message. Remember that the slave can only 
send data in response to a master’s message. 

The virtual circuit layer has three types of messages. The start and stop 
messages are used for setup and tear down. The run message is used to 
convey state and session data. It is possible for a particular master-slave 
combination have multiple virtual circuits. If so, a circuit name is used to 
distinguish them. 

The start message is shown in Figure 7-5. Before the first session can be 
initialized between two nodes, the virtual circuit layer has to initialize the 
underlying circuit. The start message never carries data slots (these belong 
in the run messages). It does, however, contain a variety of pieces of data 
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used to negotiate the parameters for a session. The master initially sends 
the start message, then the slave responds with its own message. 

The maximum sessions parameter is an example of a negotiated parame- 
ter. Each session requires CPU resources. In addition, too many sessions 
competing for an underlying virtual circuit means each session only gets a 
limited number of slot transmission opportunities. Limiting the number of 
sessions on one virtual circuit is a fairness mechanism. 

The master circuit timer indicates how often the master will send a mes- 
sage (and thus how often the slave will have to respond). A typical value 
for this timer is 80 ms. If the extended Ethernet uses wide-area bridges, 80 
ms may not be enough time for a packet to be sent and a response received 
before the timers expire. In a wide-area environment, the manager may set 
the timer up to its maximum of 200 ms. This degrades throughput, how- 
ever. 

The actual data in LAT is sent using the run message (see Fig. 7-6). The 
run message contains, in addition to message sequence numbers, zero or 
more slots. Zero slots would be used in the case of a tickler packet to keep 
a circuit alive in times of inactivity. Each slot contains data for a different 
session. Slots are required to use an even number of bytes, and are padded 
if they have an uneven number of bytes. The slot header contains a desti- 
nation and source ID, the slot length, and credits. 

Once the last session on a virtual circuit is gone, the virtual circuit is 
dismantled using the stop message (see Fig. 7-7). The stop message includes 
a reason indicator but no data slots. In addition to orderly termination, a 
stop message might be sent in the case of abnormalities, such as excessive 
network problems or protocol errors (i.e., an unknown session ID is re- 
ceived in a slot). 
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7-5 
SS OO SGOl Start Message 


For each circuit, the virtual circuit layer keeps a virtual circuit block (see 
Fig. 7-8). The block is used to keep track of information such as the current 
sequence number and the value of timers. In addition to the timers, the 
virtual circuit block keeps two important flags. The data waiting flag (DWF) 
is set by the slot sublayer whenever it has slots that are ready to be pack- 
aged. The response requested flag (RRF) is set by the slave to indicate to 
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7-6 
LAT Virtual Circuit 
Run Message 


The Data Waiting Flag 


The data waiting flag is a circuit layer flag. It indicates user data from the 
slot sublayer is available for encapsulation. The master sets the data wait- 
ing flag whenever it receives a message from the slave with the RRF flag set 
(even if the message is out of sequence). The master also sets this flag if it 
has data waiting to send. The DWF flag is cleared whenever there are no 
more slot sublayer buffers. The slave also sets the flag if it has data from 
the slot sublayer. Note that the slave will never receive a message from the 
master with the RRF flag set. 

If slots arrive faster than the virtual circuit message transfer, the data 
waiting flag is always set. Otherwise, at some point the circuit becomes 
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7-7 
LAT Virtual Circuit 
Stop Message 


idle. When the data waiting flag is set on the master, it stuffs as many slots 
as it can fit into a message and passes it off to the data link layer. It does 
this until the data waiting flag is clear, there are no transmit buffers, or the 
maximum window size is achieved. 


Balancing the Circuit 


Normally the LAT operates in unbalanced mode: The master sends mes- 
sages every time the circuit timer expires; the slave immediately acknow- 
ledges. Note that the master always sends; this allows the slave to send any 
data it has. Since the slave in normal, unbalanced mode cannot send data 
on its own, it uses the acknowledgment to send data. 

If there are no data to send, however, unbalanced mode is a waste of 
resources. If the slave sees it has no data to send, that it has acknowledged 
everything from the master, it will send a balancing message. This puts the 
circuit into balanced mode and no more data goes across the link. 

In balanced mode, either node can send. This means that if the slave 
gets data, it can send unsolicited messages up to the current window size. 
It is possible for the slave to send several balancing messages in a row with- 
out the data waiting flag ever becoming set. 

When a balancing message is sent out, it usually does not have to be 
acknowledged. This outstanding message, however, takes up queue space 
on the slave. To get the resources freed, the slave can set the response 
requested flag. This forces an acknowledgment from the master, thus free- 
ing up resources on the slave. The slave sets the RRF flag in three cases: 


e The free buffer queue is empty, and a response is needed to free up 
resources. 
° The maximum window size is about to be reached. 
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° The data waiting flag is set; another message is needed from the master 
to send the slave slots. 


Timers 


The master uses the master circuit timer to control the retransmission pol- 
icy. It is possible for the slave in its LAT directory service messages to give 
an advertised circuit timer. The master can, if it wishes, use this. 
Retransmit timers always set to value of 1 second. When a timer expires, 
the master will initiate a path test. If necessary, it will also select another 
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path then retransmit the message at the head of the unacknowledged 
queue. 

The keep alive timer ensures that a virtual circuit is operational when 
there are no slots to transmit. When the keep alive timer expires on the 
master, the data waiting flag is set, forcing a run message to the slave. 

If the circuit lost timer expires, it is up to the session layer to decide what 
to do. For example, the session layer may stop the virtual circuit and tell 
the user or it may report the quality problem to the user and let it decide. 


LAT Traffic 


Figures 7-9 and 7-10 show LAT data on an Ethernet. Figure 7-9 shows the 
simple nature of LAT, consisting of a series of data messages once the cir- 
cuit is up and running. The summary portion of Figure 7-9 shows the vir- 
tual circuit header. The message is a run (data) message, and the slave has 
not set the response requested flag. The message contains only a single 
data slot. 

Figure 7-10 shows both the virtual circuit and slot layers of a LAT packet. 
Notice there are sequence numbers for both sides of the conversation. The 
single slot includes 8 bytes of data, but no credits are being transmitted. 


Session Layer and Slot Sublayer 


The slot sublayer is transparent to the user. It is responsible for session 
state transitions, flow control and buffer management, and multiplexing. 
When the session layer has data to send to its peer, it submits the data to 
the slot sublayer. The slot sublayer, in turn, buffers the slot until the vir- 
tual circuit layer is ready for it. 

The session layer is the interface to the LAT service. It allows the user to 


e establish and terminate a session 
¢ do data transfer 
¢ interface to the LAT directory service 


Session establishment in LAT is based on names. We assume the user 
knows the name, either a priori or through the LAT directory service. Once 
a name is found, the session layer will use the LAT directory service to find 
the node with the best service rating. A slave in LAT cannot initiate a ses- 
sion, but it can send out a connection solicitation. 

The session layer provides the user with three channels of communica- 
tions: , 


e data A 
° data B 
° attention 
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Both data A and B are flow controlled. Typically, data A would have regu- 
lar data and data B would have status and control information. The atten- 
tion channel is not flow controlled and is only for small amounts of infor- 
mation. 

The actual use of the different slots is up to the user programs. LAT 
defines service classes that contain the semantics of the information in the 
different slots (e.g., the fact that a control/Y is an interrupt instead of a 
redisplay). 

Figure 7-11 shows the format of the three different data slots. Notice that 
all three have an identical format, with the constraint that credits are ig- 
nored on the attention slot. 


Session Level Flow Control 


Flow control at the virtual circuit layer was based on a window scheme and 
acknowledgment timers. At the session layer, it is based on credits. A user 
cannot send unless it has a credit—the session interface will reject the at- 
tempt. If it is rejected, it is up to the local port to implement some flow 
control policy. For example, the terminal port could beep the terminal, 
thus signaling the user that data-are being thrown away. 

Up to 15 credits may be extended at any time. As soon as slot data are 
given to the user, the credit should be returned. The credits ensure that if 
more than one user has data to send over a single virtual circuit, the slots 
are fairly allocated. A typical way to provide fairness is to limit each ses- 
sion to one slot. This guarantees each session one slot in the outgoing mes- 
sage. Just before the message is submitted to the virtual circuit layer, any 
additional slots are added. The additional slots are on a sort of standby 
basis. 

Two other mechanisms are used to ensure fairness. First, when a circuit 
transmit buffer becomes available, loading of slots starts at different ses- 
sions. This prevents a session from being permanently frozen out when 
there are many sessions sharing a circuit. Second, the slot size is limited. 
This causes credits to be used up faster, allowing more sessions to be ac- 
commodated. 

Within a virtual circuit message, the attention slots always go first, fol- 
lowed by the data slots. Note that the data slots are phase-locked: within a 
particular session data A and data B appear in the order the user submitted 
them. If we get an illegal slot (a gross violation), we terminate the whole 
virtual circuit and all sessions that use it. 


Other Slot Types 


Figure 7-12 shows the start slot used to set up a session between two ports. 
This slot, contained in the virtual circuit run message, is sent after a virtual 
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circuit has been initialized. The start slot contains a series of names for the 
desired service and the user. It also contains the minimum size for a data 
buffer and attention buffer, as well as the connection solicitation ID. The 
connection solicitation process, used to reserve a service, will be examined 
in more detail later. 

The other two slot types are shown in Figure 7-13. The reject slot is used 
to reject a session. The stop slot is used for orderly termination of a ses- 
sion. Both use a reason code to indicate why a session was terminated. 

Once the session is established, each session has a session control block, 
maintained at each of the two nodes communicating. The block (see Fig. 
7-14) keeps track of local and remote credits. It also contains flags indicat- 
ing if there are data ready to send and if there is an attention buffer. By 
consulting the session control block, a node is able to decide whether that 
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particular session needs to send data and, if so, the maximum size allowed 
for transmission. 


Service Classes 


Service classes extend the functionality of LAT by defining the semantics 
within a data B and attention slot. Two service classes have been defined. 
Service class 1 is for interactive terminals; class 2 is for loopback and test- 
ing. 

The service class information is contained in the start slot. It is up to the 
slave node’s session layer to deliver the connection request to the appropri- 
ate subsystem. The question of the service class is transparent to both the 
virtual circuit and the session layers. This concept is equivalent to the ob- 
ject in the Phase IV Session Control layer—an indicator of the type of appli- 
cation that should receive this particular session request. 
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Averton Balter Read Semaphore indicating if any attention buffers are 
y available; user can supply more 
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Service Class 1 


We can think of an interactive terminal session on a terminal server as 
having three databases: 


¢ the local physical port characteristics 
e the remote physical and status characteristics 
* the current status attributes 


Examples of the physical port characteristics include the receive and trans- 
mit speed, the parity type, the frame size, whether a bell is sent on discard 
of data and the presence of modem control. Status information includes 
things like errors (framing, parity, overrun) and the status of the session 
(are data passed through?). All changes to this type of information are done 
through the use of the data B channel. The service class 1 has extended the 
data B to include two subtypes: the set and report slots. 

To indicate which type of subslot is being used, bits 5 and 6 of the con- 
trol flags in the slot header are used. Bit 5 set is a set slot, bit 6 set is a 
report slot. 

In addition to the data B slot extension, the service class extension in- 
cludes a definition of the attention slot. If bit 5 is set in the attention slot 
header, it indicates the node should abort processing the current data A or 
data B slot, flush all receive queues, and return any credits. If bit 4 is set in 
the attention slot header, it indicates a modem poll. The current DCE and 
DTE states should be sent in an attention slot. 


oy 
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The start slot has been enhanced with a set of flags that show which DCE 
and DTE circuits are being used, if this is a modem-controlled device, if dial 
up access is permitted, and other relevant communication information. 


Directory Access Control 


Each named object in LAT (ports, nodes, services) has an optional access 
control list as part of the LAT directory service. When a request is made to 
the LAT directory service, the user supplies an identifier list (IDL). The re- 
questor’s IDL is compared with the object’s access control list (ACL). Each 
list consists of a set of up to 256 groups. Each item in the list is a group 
number. The ACL or IDL is up to 256 bits long, each bit represents a group. 
If the bit is 0, the group is missing; if the bit is 1, it is present in the list. 

The access control process is not a security mechanism. Instead, it is a 
way of partitioning services and other resources among different groups. 
This way, a user in one group has no need to see services intended for 
another group. 

As an example, assume there are two work groups of users sharing a 
large LAN. Some resources are specifically intended for each of the work 
groups. Others are LAN-wide resources. Each service is then put into one 
of these three categories. A particular user is a member of two groups in 
the ID list: the LAN-wide group and one of the two work groups. This parti- 
tioning means that when a user requests a directory listing, the user does 
not have to see irrelevant resources in the listing. 

A service is always the object of a request, not the initiator. It therefore 
only has an ACL. A node or a port, on the other hand, may be both the 
object and the requestor. It may therefore have both an ACL and an IDL. 
The port list must be a subset of the node’s list since access control will first 
be tested at the node level for establishment of the virtual circuit. 

Figure 7-15 shows which type of list is included in which LAT message. 
In a start slot, the user includes an IDL. The session service will compare 
the IDL with the target service’s ACL to see if there is a match. The other 
message types shown in Figure 7-15 are used in the connection solicitation 
and advertisement process to filter out illegal or unnecessary requests for a 
particular user or service. 

Lists are used to filter directories as well as provide access control to serv- 
ices. For example, a master node will ignore a solicit information or service 
announcement from slaves belonging to other groups. 


Connection Solicitation 


An interactive terminal is one with a human being behind it. Another kind 
of terminal on a terminal server is the application terminal. This one has 
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an application driving it. A typical example is the printer. When an appli- 
cation terminal is being used on a terminal server, the roles of the host and 
the terminal server are reversed: The terminal server becomes the slave and 
the host becomes the master (see Fig. 7-16). 

Under normal circumstances, only the master can solicit a connection. 
The mechanism in this section describes how the slave can let the master 
know it wishes to start a session. Related to session solicitation is the con- 
cept of queuing for services. 

To see how the concepts are related we can look at a typical scenario. 
The master tries to access a service on the slave. The service is in use and is 
thus unavailable. LAT allows the request to be queued. When the resource 
becomes available again, it is up to the slave to let the master know that it 
can attempt to start a session again. 

When a request for a resource is submitted, it will be either accepted, 
rejected, or queued. Every request submitted by a master contains a re 
quest ID. If the request is queued, a request ID is put into the queue. 
Along with the request ID, the object (slave) returns a queue entry identi- 
fier. 

The requestor can then do one of three things: It can wait until the object 
becomes available. It can request queue information, either for this particu- 
lar entry or for the whole queue. It can cancel the entry. 

The process of solicitation and queuing is managed by the command and 
status messages. These messages are composed directly by the session 
layer. Instead of being put into a slot, they are submitted directly to the 
virtual circuit layer where they are sent as datagrams. This makes sense 
since there may not be a virtual circuit in existence to the target node (and 
in any case, if there were, slots would not work since they must be identi- 
fied with a session). 

The command message is used to solicit a connection (see Fig. 7-17). So- 
licitation can begin with either the slave or master. For the first exchange, 
it would typically be sent by a master, requesting access to a queued serv- 
ice. The object would send back the request ID along with the entry ID (the 
position in the queue). Note that command and status messages are simply 
for queue information and the availability of services. To start the service, 
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7-16 Reverse LAT 


we will still need start and stop slots (with the associated virtual circuit 
messages underneath). 


A typical exchange might be as follows: 


¢ Master requests service (command). 

¢ Slave returns entry ID (status). 

¢ Master requests status (command). 

¢ Slave returns status (status). 

¢ Slave informs node service is available (status). 
° Master sends start message to start session. 


Queuing for services can be on a service basis or on a particular port. 

Note that the requestor is able to examine the whole queue; there is no 
access control to prevent the user from seeing who the other queue mem- 
bers are. Deleting an entry can only be done by the requesting node (or the 
local network management). 

When a status command is returned, it contains the position of the re 
quest within the queue. These are approximate positions; in the time it 
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takes the message to be processed, sent, and received the queue could have 
changed. 

If a node sends multiple status messages, the subject of the request may 
return all status information in a single status message. The requesting 
node must be prepared to filter the entries. If the subject node returns 
more status information than is requested; the requesting node must again 
be prepared to filter. 

Part of the command message includes two status request indicators. 
The user can request a status message be sent 


° periodically 
¢ whenever the queue depth changes 


The command and status process maintains five timers: 


¢ The multiple status timer is the gap between individual status messages 
so they are not bunched close together. 

° The status report timer indicates how long to wait in between periodic 
status messages. 

¢ The response timer is how to wait before retransmitting a message to 
which there is no answer. 

¢ Command retry timer indicates how long to wait before giving up on 
retransmission attempts and giving up the connection request. 

¢ Status retry timer indicates how a service will keep a resource available 
after sending the status message to the requestor. 


Figure 7-18 shows the format of the status response message. Note that 
there may be several different entries in a status message. It is up to the 
requesting node to filter out those entries in which it is not interested. 


LAT Directory Service 


The session layer translates a service name request into a node name that 
provides that service. The virtual circuit layer will then use the LAT direc- 
tory service to translate that node name into a 48-bit data link address. 

The LAT directory service is based on a multicast capability, which is 
responsive to LAN topology changes. The LAT directory service uses three 
types of messages: 


¢ The service announcement is multicast by slave nodes. 

¢ The solicit information message is either multicast or physically ad- 
dressed. 

¢ The response information message is physically addressed to the mas- 
ter that did the solicitation. 
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It is possible for an LAT implementation not to support the LAT directory 
service and to enter all information manually. Needless to say, this means 
the dynamic load balancing does not work, and we cannot really tell if a 
service is even working. The solicitation and response are for nodes which 
do not listen to multicasts—slaves and dumb masters. 


Service Ratings 


Each instance of a service offered on a node gets a service rating. Remem- 
ber, a particular service can be offered on different nodes. Thus, each 
node-service pair gets its own rating. A rating can range from 0 to 255. A 
rating of 0 means the node is highly likely to reject sessions, a rating of 255 
means the node is highly likely to accept sessions. 

It is up to each node to decide what the semantics of a node mean and 
how to assign ratings. Ratings can be static (i.e., 0 when service is gone, 255 
when it is up) or dynamic. An example of a dynamic rating is on the VMS 
operating system, where the service rating includes factors such as the CPU 
type, the number of login slots, and the amount of idle CPU time. 


Multilink nodes and the LAT directory service 


The LAT directory service will detect the set of different data link addresses 
a node uses. It then recommends to other LAT components which of sev- 
eral available working paths to use. The LAT directory service also tests 
data link paths when they fail. 

Note that this is not a routing protocol: The Cartesian product of all data 
link station addresses forms the set of available paths between two nodes. 
Each of these is treated as a point-to-point, equal-cost link. Paths are then 
chosen on a round-robin basis. 

When to use a new path depends on which component is transmitting. 
The circuit layer will select a new path every time the circuit timer or re- 
transmit timer expires. The session layer will select a new path whenever a 
connection solicitation is transmitted. 

If a component suspects a path is not functioning, it will tell the LAT 
directory service. The LAT directory service will eliminate its use by other 
LAT components and then test the path. 


Advertisement 
A slave will advertise its state in three circumstances: 


° on initialization 
* on expiration of the periodic slave multicast timer 
* on shutdown 
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During the periodic multicasts, the advertisement includes a message in- 
carnation field (see Fig. 7-19). If any information has changed, the message 
incarnation field is incremented, and the bits in the change fields flag are 
set. At shutdown, a node will try to send at least two messages, with the 
shutting down status set in the node status field. 

When a master receives an advertisement, it first compares the incoming 
access control list to the ID list on the node. If there is a match, the mes- 
sage is added to the cache. If the message is from a new node, a new node 
entry is created. The source address and the address of the local LAN con- 
troller are added as the first possible address path. When subsequent mes- 
Sages are received, the message incarnation field is checked to see if there 
have been any changes. 

If the cache is limited in size or if there is no cache, the solicit informa- 
tion message asks for information on a node or on a service (see Fig. 7-20). 
The solicitation can be physically addressed if the node and path are known 
or can be multicast out of all of the node’s LAN ports. The solicitation in- 
cludes a solicitation identifier, used for correlating incoming responses. 
The response timer indicates how long a node will wait. The solicitation 
also includes the name of a target node and the name of the desired serv- 
ice. Either of these names might be blank. 

The response to the solicitation includes information on the node and 
optional information on one or all services. It is possible that a node may 
get multiple solicitations if there are multiple paths. The node should re 
spond to each one separately; the requestor will use the multiple responses 
to build a list of working paths. 

Each solicitation has an identifier. This ID is used on all copies of the 
solicitation and is used by the requestor to correlate incoming responses. 
Figure 7-21 shows the format of the solicitation response. Note that when a 
solicitation is sent to a multicast address, it is possible that several nodes 
will attempt to respond. To prevent excess collisions on the LAN medium 
(or deafness at the requesting node), each responder will delay a random 
period of time, known as jitter. 

A solicitation can include a null or nonnull node name. It can also in- 
clude a null or nonnull service name. Finally, it can be multicast or physi- 
cally addressed. Whether a node should answer or not is shown in Figure 
7-22. 


Directory Caches 


Caches are typically limited in size. If necessary, the cache entries are 
eliminated in the following order: 


e Eliminate those that have definitely timed out: The circuit retransmit 
limit was reached on an active virtual circuit. 
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Message 


e Eliminate those that may have timed out: No service announcement 
has been reached for more than five times the slave multicast interval. 

¢ Eliminate those nodes that indicate they are shutting down. 

¢ Eliminate reachable nodes that have _no virtual circuits currently oper- 


ating. 


If after purging all this the cache is still full, the node should ignore LAT 
directory service messages. Note that if a virtual circuit is connected, cache 


information must be maintained for that node. 


240 Analyzing DECnet/OSI Phase V 





a 
© 
> 
Q 
© 
m 
— 
a 
n 















Protocol Format 


High Protocol 
Version 


Low Protocol 
Version 


| Current Protocol 
| Version 


| Current Protocol 
ECO 
Receive PDU Size 
Solicit Identifier 
| Response Status 
Source Node Status 


Node Multicast 


iNode, UID.. vanes. | 

| Length 

| Description 

Serio oguntemweays 


Summary 





Slave, Master, 
Disabled? 





7-21 
LAT Solicitation 
Response 


LAT is a direct user of the Ethernet service and is thus limited to the 
boundaries of an Ethernet or extended Ethernet. LAT is composed of two 
types of nodes: the master and the slave. The slave is typically a general- 
purpose host; the master is a terminal server, an X Windows Terminal, or a 
workstation with the LAT protocols (i.e., a PC running DECnet/DOS). 
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7-22 Responses to Solicitations 


A slave has a series of applications, known as services in LAT. Each serv- 
ice is named and includes a service rating and multiple nodes can provide 
the same service. The LAT directory service on a master node keeps track 
of available services, and logs the user onto the service provider with the 
best service rating at the time. 

LAT is timer based; a master will periodically send a message with zero 
or more slots. The periodic message exchange and multiplexing of multiple 
sessions into a single message is important for a host, reducing the number 
of interrupts and eliminating the need to poll different users. LAT thus 
places a good part of the load of a terminal session on the master, freeing 
up host resources. 
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Data 


In earlier chapters, we concentrated on issues concerning the network infra- 
structure including the presentation of data, session establishment, trans- 
port circuits, and name resolution. None of these services, however, is of 
direct use to the user. With LAT, we saw something closer to the applica- 
tion a user would see. LAT provided the infrastructure that allowed a com- 
munications program on a terminal server to send and receive data from a 
host. Even there, however, the actual semantics of the application-level op- 
erations were avoided. 

In this chapter, we move to the application layer and begin examining 
some of the services available to the user. Even here, many of the services 
are not directly seen by the user. For file access, for example, a user sees 
the operating system interface, known as a command processor. The com- 
mand processor in turn issues commands to the file system, which then 
uses the network-based file services. 

Although the application layer is at the top of the network protocol stack, 
it is at the bottom portion of the user’s protocol stack. The user sees operat- 
ing systems, file systems, windowing systems, word processors, and a vari- 
ety of different native services. Most of these services ultimately use the 
network applications, which in turn use the underlying layers of the net- 
work. You can think of this process as peeling an infinitely layered onion. 
This chapter looks at one particular form of network application—access to 
data located on a remote computer. The goal of this service is to make the 
disk drive on a remote computer appear locally attached. There are a vari- 
ety of different ways to accomplish this task. 

Figure 8-1 shows different file access protocols arranged by the degree to 
which they integrate different systems. The most integrated system (in a 
Digital computing environment, at least) is the symmetric multiprocessor 
(SMP). This is a single computer with several different processors. All the 
different CPUs are able to access a single pool of shared memory. The local 
lock manager and a single CPU scheduling processor arbitrate which CPU 
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Tightly-Coupled 


will access, and thus process, which portion memory at a given time. As 
long as a system has several different users or a single program broken up 
into several processes, the symmetric multiprocessing capability looks like a 
single CPU with shared memory. 

The VAX cluster, which uses the System Communication Architecture, 
provides a slightly looser degree of integration. In the VAX Cluster, each 
CPU has its own memory. Memory is not shared among processors unless 
a particular system is an SMP system, but appears as a single processor as 
far as the VAX Cluster is concerned. 

To share information in memory, the VAX Cluster protocols are used to 
exchange packets of information. One of the exchanges made is for distrib- 
uted lock management. Here, all of the systems communicate with each 
other before granting a user access to a portion of the file system. 

Once the lock is granted, a CPU sends a VAX Cluster message down to the 
HSC controller asking for a certain block of the disk. The HSC, using the 
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Mass Storage Control Protocol (MSCP), provides the service of delivering 
blocks of data. What the blocks mean and how they are arranged into files 
is up to the computer to interpret. 

The VAX Cluster is an example of a disk service: The remote computer 
does not interpret the data on the disk drive. A higher level of service is 
the file service. The information on a disk is structured as a series of files. 

The Distributed File Service (DFS) is an example of a file service used 
strictly within VAX computers that use the VMS operating system. With 
DFS, a remote computer can deliver files to a local computer, making them 
appear as if they were locally mounted. 

Within a file, a file service does not interpret the data. A file is simply 
one or more blocks of data. It is up to the file system on the requesting 
computer to interpret how those blocks are broken up into records or some 
other form of structure. The highest level of service is when the remote 
computer breaks a file up into records, pages, indexes, and other ways of 
structuring a file. In this record service, most of the load is placed on the 
server. When the client gets data, they have been interpreted already and 
can be fed directly into a program. Digital’s Data Access Protocol is an ex- 
ample of a Digital record-based network protocol. With DAP, users can per- 
form operations such as asking a remote computer to search a file for all 
records meeting particular search criteria, and then sort the information 
before sending it back over the network. 

DAP works fine in DECnet implementations, but it lacks generality for a 
truly open systems environment. The OSI File Access, Transfer, and Man- 
agement (FTAM) provides a similar record service to DAP but does so as an 
OSI application instead of a DECnet application. FTAM is one of the funda- 
mental OSI services used to connect a wide variety of different systems. 

File systems provide a basic level of data interchange in a distributed 
environment. The problem with file access, however, is that the program- 
mer must provide the code to break the file into the underlying fields. A 
database system provides an even higher level of abstraction than the file 
system. With a relational database system, the programmer can begin deal- 
ing with the semantic content of the data, asking the remote server to proc- 
ess queries that have a variety of complicated conditions. 

Asking the remote server to do the bulk of the processing allows the data- 
base server to be a highly optimized server. The database server can be a 
very powerful system, with large amounts of main memory and disk space. 
Workstations are able to access that data without using an inordinate 
amount of local processing power. This means the workstation can be opti- 
mized for the semantics of the user interface—how data should be pre- 
sented and displayed—instead of the brute-force sorting and filtering of 
data from a large database. 
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Data Access Protocol 


We begin our discussion of remote access to data with DAP for historical 
reasons. DAP was the original remote data access mechanism in DECnet 
and still maintains a large installed base of users and programs. As we will 
see, the DAP capabilities closely parallel the file system capabilities in Digi- 
tal’s VMS operating system, making a remote VMS-based VAX appear just 
like a local one. 

The VMS operating system provides a variety of services to the user. The 
interactive user sees the Digital Command Language (DCL), a command 
line processor. There are also programmatic interfaces to the operating sys- 
tem used for programming languages. When either a program or a DCL 
user needs access to data, calls are issued to the Record Management Serv- 
ices (RMS). RMS in turn insulates the user from all different types of data 
access. When RMS receives a call, it examines the “device” name being 
accessed. Based on a lookup table, it then hands the request to a device 
driver. 

The usual device driver is the local device driver: a combination of soft- 
ware and hardware that sends a command over the peripheral bus to access 
the hardware that makes up the disk drive. For network-based access, RMS 
hands the request off to a set of Network File Access Routines (see Fig. 8-2). 
Typically, these routines will send a request down through DECnet to a 
process called a File Access Listener (FAL). The FAL is a DAP-speaking proc- 
ess whose function is to negotiate the file system on a remote node and get 
the desired data. The FAL looks to that remote system like a user. 

Once the data are retrieved by the FAL, the FAL packages the information 
in a set of DAP packets and sends them down to DECnet. DECnet sends the 
data back over the network and hands them up to the Network File Access 
Routines; the information then goes up to the user. 

The power of this model is considerable. A programmer can use a logical 
file name in a program. At runtime, that logical name is translated to a 
particular device. A program can begin by using a local disk drive. Later, 
the logical name can be changed to point to a remote disk drive. This 
means that without recompiling or changing a program, a user can access 
both local and remote data. 

The FAL model of remote data access can even be used to access foreign 
file systems. For example, the Digital Data Transfer Facility (DTF) uses the 
DAP protocols to access data on an IBM mainframe (see Fig. 8-3). A special 
application-layer protocol is sandwiched between the DECnet Session Con- 
trol layer and DAP. This Gateway Access Protocol (GAP) sets up a session to 
the System Network Architecture (SNA) Gateway, a specialized server on the 
network. The gateway, in turn, sets up an SNA session onto the IBM main- 
frame. At the mainframe, the program is an implementation of the FAL for 
the MVS operating system. 
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8-3 DEC Data Transfer Facility 


The actual user of the FAL on the IBM can be one of three different 
sources. The remote DECnet user can use DTF to access IBM-based data 
transparently, just as the user would access DECnet or local data. In addi- 
tion, the IBM-based user can use an interactive MVS Time Sharing Option 
(MVS/TSO) command processor or a menu-based ISPF Dialogue (a series of 
forms) to access data in the Digital environment. 

All of this access, both internal to the DECnet and foreign environments, 
is subject to the security constraints in both environments. The FAL runs 
as a user process and is thus subject to access control and authentication 
requirements. In the IBM environment, the user must be registered with 
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an access system such as Top Secret or the Access Control Facility (ACF). In 
the Digital environment, access information must be explicitly passed with 
the request or must be present in the form of a proxy login on the remote 
system. 


DAP Files 


DAP was designed initially to work on PDP systems, followed by VAX sys- 
tems running the VMS operating system. Since then, DAP has been ported 
to run on Unix and DOS operating systems plus a few others, such IBM’s 
MVS and the Apple Macintosh. Despite the recent ports, the reader will see 
a definite VMS orientation in the protocol. 

DAP supports a variety of different file organizations (see Fig. 8-4). The 
basic file types are fixed-length, variablelength, and stream formats. In a 
stream format, the file is a string of data, and the application must provide 
any internal structure. Stream formats closely parallel the file system on 
Unix operating systems. 

Within a record-oriented file, there can be additional structure imposed, 
known as an extended file type. In FORTRAN carriage control, for example, 
the first byte is used to indicate things like formfeeds. In the print file 
carriage control format, 4 bytes contain both prefix and postfix information. 

The data inside of the file can be of three different formats: 


¢ ASCII text 
¢ EBCDIC 
° image 


Image data is a simple bit string transmitted with the low-order bit of the 
low-order byte first. For all three data types, DAP also offers a compression 
option to eliminate duplicates (see Fig. 8-5). 

When compression is used to eliminate duplication, normal data are pre- 
ceded by a byte that indicates how long the normal data string is. If the 
high bit is set to 0, it indicates that they are normal data. If the high bit is 
set to 1, it indicates that duplicates will follow. For nulls, the two high bits 
are 1 and 0, followed by a 6bit count, allowing up to 64 nulls to be repre- 
sented as a single byte of data. Other characters can also be compressed 
but not quite as efficiently. The high bits are set to 110, followed by 5 bits 
of a repetition count, allowing up to 32 characters to be represented by 2 
bytes of data. 


DAP message exchange 


DAP can operate in several different modes, allowing different levels of 
functionality. A primitive implementation of DAP, for example, can offer 
only the file transfer mode that allows an entire file to be sent across the 
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8-5 
DAP Data 
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Repeated character | 


network. . All data are sent in a continuous stream with explicit acknow- 
ledgment at the end of file (EOF). 
Four other modes provide a more sophisticated access to a file: 


e Random Access Mode. Access on per-record or block basis. DAP oper- 
ates in request/response mode for random access. 
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° Record Data Access Mode. Allows access based on the relative record 
number, record file address, virtual block number, string key, or byte 
offset. 

* Block Data Access. Access data based on 512-byte blocks. 

° Stream Data Access. File is a continuous stream and any structure is 
provided by the using application. 


A DAP session consists of a single logical link for each remote file access. 
The same logical link can be used for different files if there is no overlap. 
There is no multiplexing of multiple files within a single link. If a program 
wishes to perform such an operation, it would set up a separate DAP ses- 
sion for each simultaneous file access. 

All DAP files share a common message header (see Fig. 8-6). This mes- 
sage header is embedded inside of a DECnet Session Control header (i.e., it 
does not work with OSl-based stacks). The node accessing the file always 
initiates the DAP session. Each exchange is a session-level transmit request 
and receive request. A session begins with the creation of a link, followed 
by an exchange of configuration messages (see Fig. 8-7). The configuration 
messages set up the lowest common denominator of services offered and 
desired between the two nodes. 

Following the configuration exchange, a node sends an access message, 
indicating which file and the type of access desired. The FAL will typically 
send an attribute message showing more information on the file desired 
and an acknowledgment that the file is available. 

The requesting node then sends a control message. The control message 
establishes the data stream and is followed by a series of data messages. 
The remote FAL uses the service of its operating system to get data, then 
packages them up in DAP data messages. At the end of the data, a status 
message is sent indicating an EOF. The access complete message and a 
response terminate the session. 

Figure 8-8 shows a more sophisticated session involving the use of wild- 
cards. Following the beginning configuration exchange, the requesting 
node sends an access message containing a wildcard. The result is a series 
of different messages indicating the volume and directory being sent. 

Following this information, the name of the first file is sent back, along 
with an attributes and acknowledgment message. The node then has the 
option of using a control message to reserve the file and get the data. Fol- 
lowing the data and the EOF message, the requesting node closes the file. 

Then the next file is sent, along with the attributes. Notice that the re- 
questing node, not desiring this file, immediately sends an access complete 
message. If there were more files in the wildcard specification, we would 
see this process repeat several more times. 
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8-6 
DAP Message 
Header Format 


To see how this process works, we will look at each of the message formats 
involved in this exchange. The configuration message is shown in Figure 
8-9. Notice that a wide variety of different generic capabilities has been 
defined for DAP. The two nodes exchange a list of the capabilities desired 
and provided, and the union of the two sets is used for a given exchange. 
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Source: DAP Specification, Version 7.2, Page 8 


8-7 DAP Sequential File Access 


The configuration message also includes the maximum buffer size pro- 
vided. A buffer size of 0 means the node is fast enough to keep up with the 
network or the underlying session layer will provide the necessary flow 
control. 

Figure 8-10 shows an example of a DAP configuration message being sent 
by a PC. Notice that in this case (as with many DOS functions) the capabili- 
ties are quite limited, including only basic sequential files, support for di- 
rectory lists, and wildcard operation. 

An interesting capability listed in the figure is command file submission. 
In DECnet, it is possible to send a command file over the network using 
DAP and have it executed. In a system with security not set up properly, 
this leaves the possibility of stealing CPU cycles from a machine on which 
the user does not have an account. 
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8-8 DAP Wildcard Sequential File Access 


Many VAX systems have a “default” area used for general public files. 
Anybody on the network is able to access these files. Take the example of a 
programmer wishing to compile programs, a very CPU-intensive function. 
If the system on which a programmer is working is slow, the programmer 
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a 


looks for a machine with a default DAP area on the network. The program- 
mer sends the source code to the default area using a DAP copy command. 
Then the programmer sends a command file that takes the source code and 
compiles it. The programmer then retrieves the resulting object code, de- 
letes any trash lying around, and goes to lunch. The attributes message is 
used to specify the attributes of a file or the attributes needed. A bitmap is 
used to indicate which attribute fields are present (see Fig. 8-11). The data 
type field indicates not only the basic data type (ASCII, EBCDIC, or image) 
but also such options as compression or sensitive data. The record format 
indicates how an individual record looks, and the record attributes indicate 
information such as FORTRAN carriage control. 

The rest of the fields indicate a variety of different parameters available 
on a file. For example, the allocation quantity shows the total amount of 
allocated space for a file. The device characteristics allow a system mailbox, 
a tape drive, or some other device to act as a file. 

Once attributes are established, the access message is used to access a file 
(see Fig. 8-12). Based on the access message, the FAL can obtain necessary 
locks from the local file manager and open the file. Notice that one access 
type is the submit/execute used for remote execution of command files. 
The access message also includes a file specification, an access code (for 
which type of access), a sharing code (for which type of mutual access is 
allowed), and any extended attributes required. Extended attributes pro- 
vide information such as the data and time a file was created. 

Figure 8-13 shows an example of attributes and access messages being 
sent to an FAL. Notice that both of these messages are in the same network 
packet. This concatenation of upper-layer functions into a single session- 
layer packet is useful for conserving bandwidth and providing higher 
throughput. The attributes message indicates that a sequential file will be 
sent in the basic ASCII format, consisting of 8 bits per byte. The access 
message indicates that a file called “ncphelp.bin” has been opened, and will 
subsequently be retrieved. The requesting node is also indicating that it 
wishes to see a main attributes message, a data and time message, and the 
full name of the file. No password is specified for this access, so presum- 
ably the file is a public file or a mechanism like proxy login was used. 

The control message (see Fig 8-14) is used to begin the data transfer after 
the access message opens the file. The DAP control message includes a vari- 
ety of different functions, many of which are only used in specialized cir- 
cumstances. The basic control message starts a data stream. During that 
process, other control messages can be sent that change the type of access 
or specify the keys used for searching a file. 

Figure 8-15 shows a basic file access operation. The message in the detail 
portion of the screen is a control message with the get record or block op- 
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8-10 DAP Configuration Message 
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Figures 8-16 through 8-20 show a variety of other DAP messages. The 
DAP data message specifies the record number and some data. The record 
or block number is useful if packets must be reassembled by the applica- 
tion program. The continue transfer message specifies what to do if there 


has been an error. 
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8-14 
DAP Control 
Message 


When an error does occur, the status message (see Fig. 8-19) is used to 
signal the error. For example, a write operation might fail because a disk 
drive is full. The continue transfer message (see Fig 8-17) allows the reques- 
tor to try again, skip this particular operation, or abort the entire data trans- 


fer. 
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Extended Attributes Messages 


The basic attributes message is useful for specifying information like record 
sizes that is used in all transfers. Other information, however, is only 
needed infrequently. Rather than send all this information at once, DAP 
specifies a series of extended attributes messages to contain this supplemen- 
tal information. 

Figures 8-21 and 8-22 show two examples of these messages. The name 
message allows a node to specify the full file specification (useful when a 
wildcard is originally used to request a file) as well as information like the 
current directory or volume. The default file specification shows where in 
the directory tree default file access will be performed. 

The date and time attributes message (Fig. 8-22) shows the date and time 
a particular file has been created, updated, or deleted. The revision num- 
ber shows the VMS orientation of the DAP protocols. VMS, unlike many 
operating systems, labels each file with a revision number. In a typical user 
session, the last three revisions of a file are kept online. If a new revision is 
created, the earliest one is deleted. The choice of how many revisions to 
keep online is a local management decision—many system managers im- 
pose no default limit, letting users manage their own files within the limits 
of their disk quota. 

Keeping multiple revisions is useful as an online archiving technique. 
Not all operating systems have this capability and would thus omit the 
field. The fields bitmap allows unneeded information to be kept off the 
network. 

Figure 8-23 shows an example of extended attribute messages. First, a 
regular attribute message is sent, indicating this is an ASCII file, with 34 
blocks allocated and 34 blocks used. Then, the date time message indicates 
when the file was last created and updated. The name message gives the 
current directory path and name of the file. 

One of the important functions of DAP, particularly when used between 
VMS systems, is to allow random file access. The key definition message 
(see Fig. 8-24) is used to inform a requesting node what the key definitions 
of a file are. The option flag indicates whether duplicates are allowed and 
the programmer is able to change the key definitions. The fill fields show 
the target percentage that each area of the file will be filled (allowing for 
adding new data without allocating new areas or reorganizing the index). 

Not all of the fields allowed in this message would be found in a single 
message. A typical indexed file, for example, would include from one to 
eight position/size pairs for the key definition. A hashed file (another type 
of file organization) would have the hash algorithm value. 

The allocation attributes message is used to extend a file (see Fig. 8-25). 
Before large amounts of data can be added, particularly on an indexed file, 
new space must be allocated. This message indicates how much space is 


Date/Time Backed 
Up 

Physical Creation 
Time 


Message Type 





8-22 

| Last Accessed 
Date/Time DAP Date-Time 
Message 


Code = Z (Attributes) Operand Length = 28 
Attribute Data Type: Image Data 


Attribute Record Format FBSSTM; ASCII Stream format 
Allocation Quantity in Blocks 34 
Node Access Attribute Type: 
FBSFOD: A file-oriented device 
End of .File Virtual Block Number 34 
First Free Byte in End of File 256 






Courtesy of Network General 


Code = 13 (Date Time Attributes Extension) Operand Length = 37 
Date/Time (NST) Created=30-MAR-87 20:23:46 Updated=30-MAR-87 20:23:46 


Code = 15 (Name) Operand Length = 21 
Name Type: File Specification 
File Name Specification = “\DECNET\NCPHELP. BIN” 


Code = 6 (Acknowledge) 


Frame 1Z of Zé 
Use TAB to select windows 


Z Set 4 Zoom §5 bDisplyufi7 Prev fd Next 1@ New 
Teal 9 lta A Menus options™ frame frame capture 


8-23 DAP Attribute Extensions Message 


265 



















Fields "Bitmap "108 2:9 pRe Ie aeons eee aan 


Null Key character 
defined 
| No. of POS/SIZ Pairs 
(Eight Max) 


| Position of Key 
(Offset) 
Size of Key 
Position of Key 
(Offset) 
Size of Key 


Key of reference 
indicator 


Data Bucket Fill 
Index Bucket Fill 


Number of Segments 








Reference Indicator 





Reference Name 


Null Character Value 
Index Area Number 

| Lowest Level Index 

| Area 

| Data Level Area 
Number 

Data Type of Key 


Root VBN 





Hash Algorithm Value 
First Data Bucket 


< a 
an p |Z 

ee 
: 
3 * 
Ps) = 
8 L 
g 5 
Qa 








Index Bucket Size 
Level of Root Bucket 
| Total Key Size 


h 
Collating Table ID 


Size of Collating 
Table 


ke 
@ 
3 


| 


256 


8-24 
DAP Key 
Definition Message 


Data 267 




















Fields Bitmap - 


Alignment Options 


Allocation Options 


Reserved field 
Space to Allocate 
. 


Bucket Size for 
This Area 


ype = 11 
Relative Volume 
Number 













Cylinder boundary, 
logical block 
number, near file 
Contiguous 
required or best try 











8-25 
Default Extend For automatic | DAP Allocation 
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needed and if the space has special requirements, like keeping all of the 
data blocks contiguous. . 

The summary attributes extension message (see Fig. 8-26) is useful when 
a user wants to know how a file is indexed but does not need all the de- 
tailed parameter information. A user may wish to get a directory listing, 
for example, that indicates which files are indexed and how many keys are 
in them. The network file access routines would send an access message 
indicating that the summary attributes extension message should be re- 
turned along with the name of each file. 

The protection attributes message (see Fig. 8-27) is another example of a 
VMS-centric type of message. Protection on the VMS operating system is 
organized around four classifications of users: 


° system 
* owner 
* group 
¢ world 


System users have special privileged accounts. The owner is usually the 
username that originally created the file. Certain users will be in the same 
group as the owner, and everybody outside of the group is considered the 
world. For each of these four categories, there is a variety of capabilities 
that can be granted. 

DAP file protections are enforced (or subverted) by the operating system 
itself. For example, one could deny the system read access to a file. This 
does not mean the system cannot read a file, only that it would use its 
special privileges to bypass the protection scheme. The one probable result 
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of denying the system read access is that the file will not be backed up, 
since backup is an automatic program that typically skips over any problem 
files. 

The last attributes extension message is the collating table (see Fig. 8-28). 
A collating table is used to indicate how a file is to be sorted when indexed 
retrievals are to be performed. For very large collating tables, it is possible 
to include a sequence number so the message can be sent in pieces. If a 
large collating table is in use, it indicates a complex sort is needed for the 
data. Anytime that a large, multikeyed operation is consistently going over 
the network, it might be wise to investigate an alternative model, such as a 
network-based relational database management system (DBMS). The 
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DBMS, with its sophisticated query optimizer, is able to perform the differ- 
ent operations to sort data in the proper order efficiently. 


Distributed File System 


Whereas DAP provides record-level access among different operating sys- 
tems, the Distributed File System is limited to VMS-based systems and is 
meant to operate in a single LAN-based environment. Because DFS is opti- 
mized for the LAN and because it provides a lower level of structure (files 
instead of records), it operates approximately 10 times faster than DAP. 

The purpose of the DFS is to make a remote directory appear as if it were 
locally mounted. DAP allows remote file access but only if the user knows 
where the file is located. With DFS, the access is transparent. The differ- 
ence between the two is the degree of transparency: With DAP you have to 
explicitly reference the node on which the file exists (possibly using wild- 
cards), whereas with DFS the remote node becomes transparent. 

The advantage of a distributed file system is that if a file system moves, 
all that is needed is to reregister the system with the naming service. The 
user command, mount access point name, does not change. DAP and 
FTAM provide temporary access to a particular file. The file system is more 
permanent—it provides access to a file for a longer time. 

A server makes a file system available to clients using the DFS Control 
Program (DFSCP) register command. The register command lets the DNA 
Naming Service know that a particular file system is available on this server 
node using an access point name. The access point name is then used by 
the client to mount the file system. The mount command makes a pseudo- 
device that appears on the local file system as a file structured device. This 
pseudodevice will then forward requests to the DFS server. Proxy logins 
are used for authentication and authorization. 

Figure 8-29 shows the structure of the connection once a file system has 
been mounted. The application (i.e., the Digital Command Language) com- 
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municates with the Record Management Services. RMS in turn parcels out 
requests to the appropriate driver. 

For DFS-based access, the DFS client driver is used. This driver, in turn, 
uses the DFS communication driver, which is a request/response protocol. 
This communication driver would presumably be replaced by a remote pro- 
cedure call mechanism. The RPC-like communication driver then uses the 
service of a DECnet session. 

The files-11 XQP shown in Figure 8-29 is an artifact of the VMS operating 
system. In VMS, QIO (data access) requests go down to the disk driver. The 
disk driver separates out two kinds of requests. Read and write operations 
go straight down to the device. Control operations (open, close, extend, 
truncate) go up to the files-11 XQP, a subroutine library that runs in the 
user application context. Thus, open and close operations are subject to 
security because they run in the user context, whereas read and write op- 
erations (which always follow a previous open operation) run in the much 
quicker operating system confines. The server runs a single asynchronous 
control process (ACP) that provides services to multiple users. Since proxy 
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logins are used to maintain security, the files-11 XQP is available to perform 
the appropriate open and close operations. Once the context is established, 
the server driver is able to use driver context to requeue operations to the 
disk driver without causing a VMS rescheduling operation. 

The server allocates a nonpaged pool in memory for caching. Each open 
file gets some of these blocks. The caching uses a combination of read- 
ahead and least recently used methods. A block will stay in cache after a 
file close. 

DFS does not assure that writes are performed. The client needs to re- 
read the data to make sure the operation worked properly. After communi- 
cation fails on a connection, the access point remains mounted. Each user 
access to a file will result in a connection retry. When a connection is lost, 
the server will close all open files. DFS does not provide automatic fallback 
to another cluster member in the case of a node failure. 

Studies show that DFS is fairly fast. For example, compilation on a re- 
mote node only takes 125 percent of the time it would on a local node. 
Compilation is CPU intensive: File access is only a small part of the access. 
Of course, if the results of the compilation need to be transferred back to 
the home system, that adds additional overhead. 


The PC 


Digital’s VMS Services for MS-DOS are based on Microsoft Networks/Open- 
NET Architecture (MS-NET). Three services are provided: a file server, a 
disk server, and a print server. The disk server uses an area of the VMS 
disk formatted for DOS, and is used for downline loading. 

File services use the Server Message Block (SMB) protocol, which is in 
turn built on top of NetBIOS, a session-layer protocol. NetBIOS, in turn, 
uses NSP to set up the virtual circuit on DECnet (see Fig. 8-30). The VMS 
file server is responsible for mapping incoming SMB calls into the VMS file 
system. The file server is DECnet object 64—a single detached process. It is 
multithreaded, allowing multiple user’s of a single process. 

Since VMS and DOS have different file systems, the file server must do 
several kinds of mapping. File names in VMS are longer, but DOS has a 
larger legal character set. For illegal VMS characters used in DOS, the file 
server maps the character into _ XX, where XX is the hex character. Long 
file names on VMS are not shown to the DOS client. The DOS hidden, 
system, and archive attributes are not available in VMS. The VMS system 
creates an application access control list entry in the access control list. 

To simplify client access and to provide default profiles, a user requests 
services by naming a service name—an ASCII text string of 1-25 characters. 
The file server maintains service names in a file server database. A service 
has the following attributes: 
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¢ root directory (entry point) 

° service type (system, application) that defines the level of security pro- 
tection 

¢ default RMS protection mask 

¢ RMS file types (stream, or 512-byte fixed-length sequential) 

¢ VMS print queue to use 

¢ form to use on the printer 


Access to a service is based on an access control list. 


Authentication 


The Session Control layer of DECnet will authenticate a user, but does not 
pass authentication information up to the application. This presents a 
problem, since the VMS file server is multithreaded. What Digital did to 
provide authentication was to extend the SMB TREE command, which in- 
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cludes a password field. Digital then encoded the user name into the serv- 
ice name field. Instead of just a service name, the field reads: 


service%username 


The server uses this information to authenticate the user, using the 
rights-list database and the User Authentication File (UAF). Note that this 
scheme has some potential pitfalls such as when an application wants to 
keep data in a shared area. 

Each service is one of three types: system, application, or user. The sys- 
tem and application services allow all users to read and update all files in 
the area. The user-level security is on a per-user basis, using standard VMS 
access control facilities. 


Locking and the Disk Server 


MS-NET and DOS allow byte range locking, which is very different from the 
RMS scheme based on records. Therefore, the VMS file server maintains its 
own lock manager. This lock manager, in turn, uses the service of the VMS 
lock manager, taking out a private, exclusive lock on a file. In a clustered 
environment, this means multiple VMS file servers can be running. A par- 
ticular file is only available to one of those file servers. If another server 
gets a request for that file, it uses the cluster services to determine who is 
acting as the lock manager for the file, then uses DECnet virtual circuits to 
route request to that lock master. 

Access to the disk service is based on three Digital protocols. First, MOP 
is used to bring the initial module to the PC. This module then uses the 
second protocol, the Local Area System Transport (LAST), to load the second 
module. The third protocol, the Local Area Disk Driver (LAD) then loads 
the control program. The control program then loads the operating system. 
The disk server is used for remote booting. Only one user can use the disk 
at once (whereas the file server allows multiple users). 


FTAM 


The OSI File Transfer, Access, and Management (FTAM) protocols are simi- 
lar in scope to DAP, although FTAM has been provided to connect a wider 
variety of file systems. As such FTAM provides a general model from which 
implementations will pick a specific subset. This subsetting of the protocol 
is important—two implementations will not necessarily interconnect at full 
functionality if they do not support the same subsets of the protocol (or 
cannot negotiate the same subset). 

The general FTAM filestore model is of a single file, divided into a series 
of data units. A data unit consists of nodes structured in a tree. Attached to 
a node are zero or more data units. In a traditional file system, a node is a 
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file and the data units are the data inside of the file. In FTAM, the model is 
based on a single file (there is no concept of multiple files inside a direc- 
tory). In the FTAM model, a data unit is a record, page, block, or any other 
unit of structure inside a file. 

We can model most file structures within this general model. A sequen- 
tial text file, for example, consists of a single node under the root node, 
accompanied by a series of data units, one per record. A binary file consists 
of one node and one data unit. 

Hierarchical file organizations, such as the Btree or the Indexed Sequen- 
tial Access Method (ISAM), can be modeled as a multilevel tree. To lend 
some order to this potentially infinite tree, the FTAM model takes data 
units and structures them into file access data units (FADUs). A FADU is a 
portion of the tree down to the leaf nodes. Thus, the entire file can be 
considered a single FADU, just as lower-level portions can be a FADU. 

The FADU model of operation makes it easy to structure operations on 
the virtual file. Remember that actual operations on the file are performed 
by a local file operation. All that is needed by the FTAM protocols is an 
ability to communicate what operation needs to be done. 

An FTAM session consists of a series of nested regimes. These regimes 
have certain operations that can be performed. An association regime, for 
example, is necessary before a file can be selected. Next, a file is opened, 
followed by any transfer operations. Notice that access is sequential: FTAM, 
like DAP, does not provide an asynchronous model of file processing. 

The general FTAM model is broken up into functional modules, called 
service classes. Service classes structure the capabilities of the protocol into 
subsets. Document types structure the general filestore model into specific 
subsets. 

Service classes are levels of capabilities within the protocol and are nego- 
tiated by the two ends of a connection at connect time. FTAM has five 
service classes specified: 


¢ File access allows access and manipulation at the record level. 

¢ File transfer of whole files or parts of files. 

e File management: reading and changing file attributes. 

¢ File transfer and management includes creation and deletion of files. 

* Unconstrained allows negotiation on the basis of available functional 
units instead of service classes. 


Functional units are a more granular way of dividing up the capabilities 
of the protocol. Within a particular class of service, there are mandatory 
and optional functional units. You can always negotiate for optional func- 
tional units within a class of service. The unconstrained service class is one 
with no mandatory functional units. The following are the ten basic func- 
tional units defined in FTAM: 
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* Kernel: basic file services for establishment of a connection 

°e Read 

° Write 

File access: locating and manipulating FADUs within a file 
Limited file management: file creation and deletion, reading of attrib- 
utes 

¢ Enhanced file management: changing file attributes 

¢ Grouping of operations so regimes can be efficiently established 
¢ Recovery: re-creation of select or open regimes 

¢ Restart data transfer 

e FADU locking 


Whereas the functional units and service classes deal with the services 
available in the protocol, document types limit what types of data may be 
contained in a virtual file being exchanged in an FTAM regime. Individual 
users may register their own file types with the proper authorities, specify- 
ing the structure of the data units and FADUs within the virtual filestore 
model. 

In addition to user-defined document types, the ISO has defined five ba- 
sic document types: : 


FTAM-1: unstructured text files 
FTAM-2: sequential text files 
FTAM-3: unstructured binary files 
FTAM-4: sequential binary 

¢ FTAM-5: simple hierarchical 


The FTAM model is based on a single file. Most operating systems have 
more than one file, structured as a directory. A standard developed by the 
National Institute of Standards and Technology (NIST, formerly known as 
the National Bureau of Standards) provides a supplemental document type, 
that treats files in a directory as a special type of file. The user can retrieve 
this special file, then move on to individual files. 

Figure 8-31 shows an example of a typical FTAM session. Notice that the 
first thing that happens is an OSI transport protocol virtual circuit is estab- 
lished and the connection request and confirm packets are acknowledged. 

Once the circuit is initialized, the FTAM initialize message is sent, pre- 
sumably embedded within OSI ACSE, Presentation, and Session Layer in- 
itialize messages. It is possible to have the session layer reuse an existing 
transport layer connection, in which case there is no need to reinitialize. 
Once the FTAM association is in place, the requesting node sends a series of 
operations, structured together as a single group of operations. First, a file 
is created, then the file is opened in “replace, extend” mode. Replace, ex- 
tend mode is used in FTAM document types 1 and 3; insert mode is used 
for document type 2. 
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Next, the other node sends a message back acknowledging each of the 
operations. Notice that the file name returned is the full name that has 
been translated into an open on the unstructured binary document type. 
The first node then goes back and extends its file. 

Figure 3-32 shows the FTAM initialize request in more detail. Notice that 
the service is being established based on functional units. The node has 
requested write, limited file management, and grouping. Attribute groups 
signify which file attributes are negotiated for a session. 

The FTAM quality of service is used to indicate whether recovery is 
needed on this operation. The recovery and underlying checkpointing can 
make the session significantly slower: therefore if the application does not 
need it, recovery is often avoided. 

The initialize request also indicates that two document types may be 
used—the unstructured and sequential text document types. It is up to 
each side to know what the document types mean in their real file systems 
and how they are interpreted by the application. 

Figure 8-33 shows more detail on the operation to close and deselect a 
file. Notice that in between each of the FTAM commands there is a presen- 
tation layer header that indicates which of the possible presentation context 
identifiers applies to the upcoming command. Figure 8-34 shows a session 
with a data transfer operation. First a file is created, and the file extended. 
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Then, 160 bytes of data are transferred, followed by a data end (the end of 
the data) and then a transfer end (the end of the transfer regime). Then, 
the file is closed and deselected, freeing it up for other users. 

Figure 8-35 shows another session in which a file is created and opened 
as an unstructured text document. Ten groups of text data are sent, all 
included in the same underlying Ethernet packet. This is followed by a 
data end message and an end of the transfer regime. 

One of the aspects of FTAM that makes it useful is the large number of 
file attributes that have been defined (see Fig. 8-36). Attributes are broken 
up into four groups, and not all groups must be supported. 

The kernel has the basic information on a file, including the name and 
permitted action. The contents type indicates to what kind of document 
type (or a more general classification called a constraint set) the file be 
longs. Just because this information exists, it does not necessarily mean 
that the operating system will allow it to be divulged to other users. 

The storage group includes an account indicator so that charges for ac- 
cess to the file may be directed to the appropriate user. The storage group 
also indicates size and availability information (i.e., online or on tape), as 
well as date and time information. The security group is used for a variety 
of purposes. The access control indicates who may look at the data in the 
file (or perform other operations such as writing). The legal qualifications 
indicate information such as copyright that may reflect how the data may 
be used. 

Finally, a group called the private group has a single private attribute. 
This is where a particular implementation or computing environment 
would put its historical file attributes or information not supported in 
FTAM. DEC, for example, might hypothetically put a collating table in this 
area if there is no document type definition that holds that information. 
The use of private attributes reduces interoperability and is thus discour- 
aged by open systems advocates. 


Digital’s FTAM Implementation 


Digital’s FTAM runs on the ISO protocol stack. DAP runs on the Digital 
Session Control layer. It appears as if DAP is still the strategic product for 
internal communication, although, as the cliché says, only time will tell. 

Digital’s version 2 of their FTAM implementation supports the three ba- 
sic FTAM document types (unstructured text, sequential text, and unstruc- 
tured binary) and most of the functional units. Of particular interest is 
support for file recovery. 

Digital’s FTAM also includes a DAP-FTAM gateway, allowing DECnet us- 
ers to access remote OSI systems using the FTAM protocols (see Fig. 8-37). 
The gateway is essentially an FAL to the Digital user. It then translates the 
DAP calls into FTAM calls. 
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To access a remote file, the DCL user uses a special form of the DECnet 
file specification which embeds access control information and the target 
node into a single file specification. The gateway allows any DECnet user to 
access remote OSI files. DECnet and DAP are used up to the gateway, then 
OSI and FTAM are used. The gateway does have a few limitations: The user 
must give an exact, complete file specification, and wildcards are not sup- 
ported. 

A DAP-FTAM gateway can be provided because most of the basic DAP 
calls map quite easily into associated FTAM calls (see Fig. 8-38). The DAP- 
FTAM gateway provides a transition environment that allows Phase IV 
nodes to access OSI resources. In a Phase V area, the FTAM application, 
part of DECnet, is available directly to the user. 


TCP/IP-Based Services 


A subject not covered extensively in this book is the use of TCP/IP as an 
alternative to DECnet or OSI services. Both VMS and Ultrix (Digital’s Unix) 
have full support for TCP/IP and the Sun Microsystems-developed enhance- 
ments, the Network File System. 

The equivalent to DAP and FTAM in the TCP/IP world is the File Transfer 
Protocol (FTP). Given its age and the wide variety of implementations, FTP 
is not as rich a protocol as DAP or FTAM. It offers transfer of whole files 
but does not provide access to the interior structure of files. 

A more advanced protocol is Sun’s Network File System. NFS is similar 
in function to Digital’s Distributed File System, with the important differ- 
ence that NFS has been implemented on every major operating system and 
DFS is only available for VMS. NFS allows a system to mount a remote file 
system, which is useful in a campus-like environment where the system 
administrator does not know which workstation (or even which brand of 
workstation) a given user will be using. NFS allows users to mount “home” 
files onto any workstation. Little used files, such as help files, can be 
mounted on all computers but stored on a single help server. 

Digital supports NFS on all its platforms, including the VAX Cluster. 
With the VAX Cluster, the HSC controller can act as a disk server for a large 
environment of workstations—Digital and non-Digital. 

For more information on TCP/IP and NFS, the reader is directed to a 
companion volume to this book, Analyzing Sun Networks (Van Nostrand Re- 
inhold, 1991). 


The Relational Database 


We now move to the last method of remote data access—the relational data- 
base management system, which provides a level of functionality not found 
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in more primitive file systems. Typically, a DBMS uses the underlying file 
system as a method of storing data, then provides a great deal more func- 
tionality. 

The biggest piece of functionality is logical access to data. The user sees a 
series of tables composed of rows and columns. The Structured Query Lan- 
guage (SQL) is used to specify what information, perhaps spanning multi- 
ple tables, is needed. The power of this method is that the user does not 
have to worry about the underlying storage mechanisms. The type of in- 
dex, the storage structure, and other implementation details are hidden 
from the user and can be changed over time. 

The database manager uses a query optimizer to decide how to get infor- 
mation efficiently in an environment with many tables and complex que- 
ries. This specialized query optimizer means that the programmer is freed 
from worry about the process of getting data and can concentrate on the 
semantics of how to process the data. 

Increasingly, the database management system resides on a network. A 
program on the workstation issues SQL calls over the network, where they 
are received by a powerful server tuned to meet the demands of rapid data 
access. Although Digital has a clearly spelled out strategy for file-based data 
access, its database strategy is a bit more vague. Digital supports networked 
access to databases (not to be confused with the network model of database 
managements systems used in Codasyl). Networked access means the front 
and back ends are on separate systems. Networked access to relational data- 
base systems is provided by Digital using its Rdb database system and the 
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Digital Standard Relational Interface (DSRI), a network-based programmer’s 
interface. 

What Digital does not have (at least at the time that this book went to 
press) is a distributed database. A distributed database is the ability to treat 
many different databases as a single logical, distributed database. For ex- 
ample, manufacturing may keep one database, personnel another, and fi- 
nance yet a third. Often these databases are developed and maintained 
separately, but queries will often span multiple databases. A distributed 
database allows the programmer to deal with the different repositories of 
data as a single whole, rather than work with each separately. 

Distributed databases become especially important when updates are in- 
volved. One of the jobs of the database manager is to group several opera- 
tions into a single transaction, guaranteeing that either all or none of the 
operations are performed. In a distributed environment, it is possible that 
updates may span several different computers and the DBMS must con- 
tinue to ensure transaction integrity. 

One of the Digital database strategies has been to rely on third-party ven- 
dors; for example, Digital has the Rdb database for the VMS operating sys- 
tem, but nothing for Ultrix. Digital therefore uses Ingres as their embedded 
database for Ultrix. 


Summary 


Data access protocols such as DAP or FTAM are meant to make the network 
transparent. As Sun Microsystems put it in a series of advertisements, “the 
network is the computer.” 

The goal of transparent access is never totally met, but often the operat- 
ing system is able to shield the user from the details of remote data access. 
The record management services on the VMS operating system, for exam- 
ple, makes access to remote files via DAP fairly simple. 

The different protocols for data access can be categorized based on the 
level of service they provide. Disk servers such as the Vax Cluster provide a 
primitive (and consequently fast) service of access to blocks of data on a 
disk. DFS provides access to files and blocks within the files. DAP provides 
the most structured level of service with access to individual records. 

DFS and DAP both operate on the DECnet side of the protocol stack. For 
the OSI side, Digital uses FTAM. Since FTAM and DAP provide similar serv- 
ices, an FTAM-DAP gateway allows the DECnet user access to OSI-based 
nodes. 

The most transparent level of access to data is the distributed relational 
database system. Instead of worrying about files, location, and other details 
of physical data access, the programmer is freed to concentrate on logical 
data access. 
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Terminals 


The goal of a network architecture is transparency—the user should not 
even know the network is there. The computers on the network, and the 
services they offer, should appear as a simple extension of the user’s work- 
station. 

Client-server protocols and data access mechanisms are one way of ex- 
tending the workstation’s reach.. There are times, however, when the user 
needs to attach to another computer as a plain old terminal. The LAT pro- 
tocols handled the situation of the dumb terminal on a terminal server or 
by the PC emulating a terminal. Whereas LAT is limited to a single ex- 
tended LAN, the mechanisms examined in this chapter work across an en- 
tire network. The DECnet CTERM protocols use the DNA Session Control 
layer to connect to other Digital (or DEC-compatible) nodes. The OSI Vir- 
tual Terminal Protocol (VTP) lets a user connect to another OSI-based sys- 
tem. 

It is worth noting what this chapter does not cover—alternatives to the 
simple terminal.emulation. In most modern networks, users are moving 
away from protocols like CTERM and toward more advanced capabilities 
based on network-based windowing environments like the X Windows Sys- 
tem. Digital uses X as part of DECwindows. 

PostScript, the language used to talk to most modern laser printers, is 
also used as an imaging system on the graphics screen in DECwindows. 
PostScript, with its scalable fonts and sophisticated two-dimensional graph- 
ics system, is ideal for applications like desktop publishing and graphics 
editing. For three-dimensional graphics, Digital supports another imaging 
model, the Programmer’s Hierarchical Graphics Control System (PHIGS) or, 
more specifically, the PHIGS for X implementation known as PEX. PEX al- 
lows sophisticated graphics, such as supercomputer-generated visualization 
of complex models, to be displayed on the workstation screen. 

PostScript, X, and PEX are all graphics protocols for the sophisticated 
workstation communicating with applications on the host. These topics 
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could easily be put into their own book (and indeed have by several 
authors). This chapter instead concentrates on the lower-level task of sim- 
ple terminal emulation. 


CTERM 


We start with the method used to log onto a Digital minicomputer, typically 
a VAX running either the VMS or Ultrix operating systems. The protocol 
used to provide this service is known as CTERM, short for the Command 
Terminal Module, one of the components of the protocol. The goal of the 
service is to allow a host-based application to treat all terminals, directly 
attached or network based, the same way. Digital accomplishes this by 
splitting the terminal device driver into two parts (see Fig. 9-1). 

The application, via the operating system, acts as if it is communicating 
with a locally attached terminal via the services of the terminal class driver. 
The terminal class driver, based on the terminal ID, sends requests to the 
actual device driver that controls the asynchronous communications con- 
troller to which the terminal is directly attached. This split in functionality 
between a general class driver and a hardware-specific driver provides a 
level of transparency between the physical controller and the application. 
The split has another implication: allowing a PC to dial in as a terminal and 
then turn into a DECnet node. 

As we saw in the subnetworks chapter, asynchronous DDCMP communi- 
cations can be used as a method of providing DECnet connectivity. Asyn- 
chronous DDCMP is an important part of the DECnet/DOS implementation. 
When a remote PC wishes to use a modem to connect to a VAX, it dials in 
via a modem. By default, most systems connect the user to the local termi- 
nal module instead of to the network DDCMP driver. 

The user is then presented with the typical login information, validating 
the user to that particular VAX. After being validated, the user can switch 
to a DECnet connection by issuing an escape sequence. The escape se 
quence, recognized by the device driver, switches the user to the DECnet 
service provider, and thus makes the PC a member of the DECnet instead 
of just a terminal. 

Emulating a terminal allows the user to do the normal tasks of any inter- 
active user—run programs that reside on the host. Functioning as a DEC- 
net node allows the user to run all the network-based applications, such as 
DAP, directly from the PC. The two-level driver thus allows an application 
to be unaware of the local or remote nature of a user. If the user is remote, 
reads and writes to the terminal are sent to the network driver instead of to 
the local device driver (see Fig. 9-2). 

Figure 9-2 shows that the CTERM protocols are actually two separate pro- 
tocols. The lower layer, the foundation protocol, allows a physical terminal 
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on a terminal server to send and receive data to a host. The foundation 
layer allows a variety of value-added upper layers to use this basic data-de- 
livery service. The typical upper-layer module is the command terminal 
module, which allows a user to emulate a line-oriented, VT-compatible ter- 
minal (the VT series is Digital’s standard line of dumb terminals). Other 
modules allow the user to perform forms-oriented operations and to utilize 
other methods of interacting with a host. 

The foundation services thus provide basic data delivery as well as mod- 
ule switching. They also provide a logical terminal module, shielding the 
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host system from the details of the particular type of terminal. As long as 
the terminal supports the basic functionality assumed in the logical termi- 
nal module, the specific way the functionality is provided (e.g., how a cur- 
sor is moved on the screen) is irrelevant. 

In addition to reading and writing, the purpose of the protocols is to 
allow an application to manipulate the various characteristics of the termi- 
nal. Figure 9-3 shows a variety of these characteristics. The handler, for 
example, maintains information that indicates if input should be ignored at 
that moment, effectively locking the keyboard. It also indicates if normal 
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9-3 CTERM Characteristics 


echo of data is enabled and if certain characters should be passed through 
to the host (the control/o sequence is a signal that output resulting from a 
command should be discarded instead of shown on the user’s screen). 

The raise input characteristic indicates that all lowercase characters are 
converted to uppercase upon input. This allows communication with 
primitive host systems that do not support uppercase and lowercase. 

The input and output escape sequence flags indicate whether special VT- 
100 escape sequences are used for input or output. These sequences per- 
form operations like changing video characteristics, positioning the 
character, and enabling the terminal management mode. 
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Two bitmaps are provided, one for errors and one for character attrib- 
utes. The error bitmap indicates what to do when certain types of errors 
are encountered. For errors such as receiver overruns or parity errors, the 
character can be ignored or queued for transmission to the host. 

The character attributes bitmap specifies, how each character should be 
handled. The possible handling methods include: 


out-of-band handling 

including it in the input data stream 
altering the output discard state 
echoing control characters 
enabling/disabling special characters 


Out-of-band handling bypasses the normal input queue. Altering the out- 
put discard state is the control/o toggle. The echo control character indi- 
cates whether things like the control/c interrupt should be shown on the 
screen. The enable/disable indicates whether certain well-known control se- 
quences (like control/s for stop the screen) should be enabled or not. 

All of these handler-maintained characteristics operate at the upper, com- 
mand terminal module, level. A variety of lower-layer characteristics is also 
maintained by the foundation layer. Some of these are at the logical termi- 
nal module; others operate with the physical terminal. 

The logical terminal characteristics specify which operations can be han- 
dled by the terminal itself and which ones the logical terminal module 
must perform. For example, a fill after a carriage return is used to delay 
after a line in the case of a printer that needs to move a carriage back 
physically. The wrapping characteristic indicates whether the terminal can 
perform the operation of moving the cursor back to the next line or if the 
software should handle this. Loss notification indicates if, when the input 
buffer gets full, the physical terminal or the logical terminal module should 
notify the user by ringing the bell. 

As we can see, the concept of a remote terminal is more than reading and 
writing data to the screen. The particular mode of operation, in this case 
the VT-100 specific characteristics, provides a good deal of functionality be- 
yond simple reads and writes. 

If the operation were indeed a simple read/write operation, we could 
have accomplished these tasks simply by using DAP or even using the DNA 
Session Control layer directly. The functionality provided by CTERM, tai- 
lored directly to the interactive terminal user, allows interactive programs 
to be run effectively in a wide-area environment. In a local-area environ- 
ment, we will typically see LAT used instead. 
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Foundation Layer 
The basic foundation service has three functions: 


* manage the logical connection to a resource in the host (Known as a 
“portal”) with a logical terminal 

e establish and change the mode 

¢ manage data transfer 


Once a DNA Session has been established, the foundation layer performs 
a bind between the two user processes (see Fig. 9-4). The bind request, sent 
by the host after it accepts the session, indicates which version of CTERM, 
which modules, and which specific terminal on the server the host wishes 
to connect to. 

The server (which typically had initiated the session with a DNA Session 
Control connect message) then responds with a logical terminal ID and the 
operating system it is running (see Fig. 9-5). Notice that in this protocol, in 
contrast to LAT, it is the host with the application that is the master in the 
relationship. The host initiates the session and will control the reading and 
writing of data. 

Once the host is finished, as when the user types “logoff,” the host clears 
the session using the foundation layer unbind message (see Fig. 9-6). The 
message only has a reason field. The typical reason is number 5, the user 
unbind request, but it is also possible to have an abrupt termination for a 
variety of other reasons. 

The two other foundation layer messages are shown in Figures 9-7 and 
9-8. Figure 9-8 has the mode messages, allowing the user to enter, exit, or 
confirm a mode. The host can respond with a confirm or no mode mes- 
sage. Typically, the session would begin in command terminal (CTERM) 
mode, but it then might switch to forms mode for a data-entry operation or 
some other forms-oriented program such as the ALL-IN-1 office automation 
software. 

After performing the housekeeping of bind and mode messages, most of 
the session will consist of simple foundation layer data messages. The mes- 
sages contain either common data or mode control information. Notice 
that the foundation data message can contain several different data seg- 
ments, allowing a host to send a screen’s worth of data, one line at time. 
The physical terminal would typically provide an automatic carriage return 
after each line of data. 

A single user may thus transmit multiple pieces of data within a single 
subnetwork-layer packet. In contrast to LAT, however, a given virtual cir- 
cuit can only work with one user/application association at once. When 
there are several users on one server all communicating with the same host, 
each session is a separate virtual circuit. For this reason, LAT is more effi- 
cient within the confines of a single data link. LAT also provides the capa- 
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bility of naming and advertising services, providing a logical separation be- 
tween the user and the computer. 


Command Terminal Module 


The foundation layer allows the host and the server to be separated across 
the network. The command terminal module adds to this functionality by 
building more capabilities into the server system. Examples of servers 
would be a PC acting as a VT-100 terminal, a VAX VMS system with the 
“SET HOST” command, and a PDP-11/23 acting as a dedicated concentrator. 
CTERM provides a variety of functions on the server system, including 


¢ echoing 

type-ahead 

input editing 

output control (i.e., discard output) 

out-of-band input 

quoting (pass in verbatim character using control/v) 
output echo synchronization 
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9-9 CTERM Processes on Host and Server 


Synchronization ensures that commands and the results are shown in the 
proper order. This is done by locking one of the data streams at the proper 
moment. 

The CTERM module can be modeled as a set of procedures and buffers 
(see Fig. 9-9). The preinput process on the server scans incoming keys 
typed by the user and decides whether they go in the normal buffer or 
should be sent directly to the host in the out-of-band buffer. 

In addition to looking for out-of-band characters, the preinput process 
performs several other tasks. If control/x processing is enabled and one is 
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received, the process clears the type-ahead buffer. If a read is pending, the 
control/x is changed to a control/u and placed in the type-ahead buffer. If 
control/o is enabled, the output-discard state variable is toggled, telling the 
output process that the user does not wish to see more output. 

Normal data go directly into the type-ahead buffer and sit there. Data are 
moved out of the buffer only when the host issues a read command. If the 
type-ahead buffer gets full, the terminal will notify the user by ringing a 
bell. 

In addition to guarding data for the host, the input process performs 
other functions. If escape sequence recognition is enabled, it processes 
these characters. If input editing is enabled, it looks for characters that af- 
fect the command input. The following characters will affect the status of 
the input buffer: 


¢ delete deletes the last character 

* control/w deletes word 

* control/u deletes all input on this line 
* control/r redisplays the input 


Finally, the input process looks for the termination character. When it sees 
it, the command has been fully composed and the buffer can be handed off 
to the operating system. 

Normal terminator characters are the carriage return or linefeed charac- 
ters. Other terminators are when no character appears in the type-ahead 
buffer for a long period of time, when the input process gets an “unread” 
from the operating system, or when the user enters an input/editing com- 
mand but the input buffer is empty. 

When most data are sent to the host, they are also echoed on the user’s 
screen. The data are thus moved by the input process to the output proce- 
dure, which writes the data to the user’s screen. In addition to writes from 
echoing, the screen will also have data from the host, which puts data into 
an output buffer. The output process then moves that data, using the foun- 
dation layer services, to the output process on the user’s terminal. 

The output process is responsible for two tasks: 


* maintaining the output discard state 
¢ sending characters from output buffer to output procedure 


The data in the output buffer are a series of characters and flags. The flags 
are start-of-message (SOM) and end-of-message (EOM). They are put in the 
output buffer by the host terminal interface write function. Typically, the 
SOM flag will lock the output procedure. There are two kinds of EOM flags. 
The first unlocks the output procedure after the last character is processed. 
The other optionally causes a redisplay of the input buffer. 
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9-10 CTERM Traffic 
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9-11 CTERM Write Message 
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The output process basically loops, moving data through the buffer. If 
the user has XOFF (control/s) enabled, the output process will be unable to 
move data, which eventually causes the write operation at the host to fail. 


CTERM Messages 


Figures 9-10 and 9-11 show typical CTERM traffic. In Figure 9-10 we see 
that the session begins with a bind request and accept. Next, the CTERM 
mode begins sending a variety of messages to check the characteristics, then 
performs.a series of reads and writes. Figure 9-11 shows a variety of write 
messages all put in the same foundation layer data message. 

The initiate message (see Fig. 9-12) is used to form a binding between the 
two CTERM modules. It sets the maximum input and output buffer sizes 
and defines which CTERM messages are supported by a particular imple 
mentation. 

The start read message (see Fig. 9-13) is sent by the host to start the read 
process. It is sent when the host is ready to receive data and indicates how 
long the input buffer on the host is and how much data are currently in 
that buffer. The timeout factor indicates how long the server has to start 
the process. 

The end of prompt and start of display tell the server input process 
where the server’s prompt is and where the actual data are. This lets the 
server know how much data came from the user and can be affected by 
input editing. The termination set indicates which characters can be con- 
sidered line terminators. 

A variety of input flags is defined on this message to control a particular 
read operation. Underflow handling, for example, defines if a bell should 
be rung when a user tries to delete characters beyond the beginning of the 
buffer. The clear type-ahead flag indicates if the type-ahead buffer should 
be cleared. The terminate on vertical change tells the input process the 
read should be terminated if there is a change in the vertical position of the 
cursor while echoing an input character. The terminator echo flag indicates 
that terminator characters (carriage returns or linefeeds) should be echoed. 
The nondefault terminator set indicates that a set of terminator characters 
is specified. 

The server will respond to the start read message with a read data mes- 
sage (see Fig. 9-14). The message indicates where in the input buffer the 
data should be placed and if there has been a change in the horizontal or 
vertical positions. The flags indicate whether there are more data and, if 
not, the reason for the termination of the read. 

The unread command (see Fig. 9-15) is sent by the host to terminate a 
current read command if there is one in progress. The unread can be un- 
conditional or can only take effect if there are no data in the input buffers. 
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9-12 
te ae = CTERM Initiate 
i arame er Vaiue Mette 


In addition to a normal read data message, the server may send an out- 
of-band data message (see Fig. 9-16). This message does not require the host 
to initiate the transaction, but may only contain a single character. Re 
peated out-of-band data messages may be sent by the server (although the 
host will typically ignore repeated interrupts). Often, an out-of-band data 
message (such as an input) will result in a message to clear the input buffer 
of any extraneous data (see Fig. 9-17). 

When the host has data to send, it sends a write message (see Fig. 9-18). 
The message may or may not carry data. The flags indicate if there is a 
change in the lock handling by the output procedure. The beginning-of- 
message and end-of-message flags also affect the lock on the output proce- 
dure (preventing, usually, the input process from echoing data back while a 
write operation is in progress). 

Prefix and postfix codes allow special characters to be added before or 
after the data. For example, a certain number of linefeeds might be put in 
place before or after the data are sent. Alternatively, a character such as a 
formfeed might be used. 

The completion status requested flag indicates that the host would like to 
know when the write operation is completed. It is possible that the write 
operation cannot be completed because the user has locked the screen. If 
so, perhaps the application would like to timeout after a period of time if it 
does not receive the write complete message (see Fig. 9-19). 


Terminals 301 









ae  Hosgeterversit | 
re 


End Of Data Start of Available 
Space 


0 Means Process Now _| 


| Position in Input 
End 
Start Of Display es in Input 

| Last Char Not | 
Termination Set Bit map up to 32 Bytes | 

RNase ero + MER Chaguoier 


UU: Underflow Handling Definition 


| C: Clear Type-Ahead Flag 
F: Formatting Flag: Add LF to CR; Ignore Preloaded LF 


V: Terminate on Vertical Change Flag: Terminate 
read if change while echoing 

| K: Continuation Read Flag: Continuation of previous 
read? 



































II: Raise Input Flag: Convert Alpha to Uppercase | 
| 


DDD: Disable Control Definition: Disable some or all 
control characters 





9-13 
CTERM Start 
Read Message 


The write complete message also allows a host to know where the cursor 
is after the last write operation. Remember that local echoing may have 
affected the position of the cursor. Knowing this position allows the host to 
determine if a formfeed or some other control may be necessary. 

The read characteristics message (see Fig. 9-20) allows the host to read the 
characteristics maintained by the server foundation or CTERM modules. 
This information, previously presented in Figure 9-3, lets the host find out 


information about the state of a particular terminal. 
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CTERM Read 
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CTERM Clear 
Input Message 
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When a characteristic is modified, either the host or the server can com- 
municate this information with the modify characteristics message (See Fig. 
9-21). When the host sends the message it is a command to change a char- 
acteristic. When the server sends the command back, it is a notification of 
the current state. 

Both the read and modify messages contain selector and value fields. 
The selector picks which characteristics are to be modified or reported, and 
the value is the current or new value. 

There are three more messages available that modify the state of the op- 
eration. The discard state message (see Fig. 9-22) indicates to the host that 
the user is not interested in the rest of the output from the previous com- 
mand and that the output can be safely discarded. The input count/check 
message (see Fig. 9-23) serves two purposes. First, when the host sends the 
message, it is an indication to send an input count message. Second, the 
resulting count shows the total number of characters in the input and type- 
ahead buffers. Finally, the input state message is sent from the server to 
the host to show whether the buffer is full or empty (see Fig. 9-24). 
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CTERM Input 
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ISO VIP 


In the CTERM protocols we saw a DECcentric method of handling remote 
virtual terminals. Functions like the control/o keys (discard output) are ori- 
ented around asynchronous terminals in general and the VT-100 series in 
particular. The ISO has a more difficult task of accommodating a variety of 
different models of terminal interactions, ranging from the IBM-3270 series 
of synchronous terminals to teletex and videotext terminals. 

The OSI Virtual Terminal Protocol is based on an abstract model shared 
between two communicating processes, known as the virtual terminal 
space. Within this virtual terminal is a variety of objects. A display object 
could be a terminal screen or a bell; a control object can be a devices like a 
joy stick, mouse, or keyboard. 

As with the FTAM services, the general model is too broad to be useful 
and subsets are used in an implementation. Specific models of terminal 
interaction are registered using terminal profiles. A profile might be an 
international standard, as in the case of the basic teletex terminal, or ven- 
dor specific as in the case of the VT-100 terminal class. At the time this 
book went to press, Digital had not released details of how it would support 
VTP, so this discussion is fairly general. 

The VTP protocols use the OSI Session Control layer to set up a session 
with a remote system. The presentation layer and the Association Control 
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9-25 VIP Associate Request 


Service Element then set up the association between two applications (see 
Fig. 9-25). Notice that the session uses a presentation context previously 
defined for use in the VT model. 
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9-28 ISO VIP Display Objects 


The actual VT associate request specifies both basic and extended models 
of operations. Basic operation is simpler to support. In this particular ex- 
ample, the requestor specifies that no additional functional units shall be 
used in this session. The response to the associate request is shown in Fig- 
ure 9-26. The negotiation was a success. If there is a collision of data being 
sent by the two sides, the initiator is the winner. Functions like profile 
switching or urgent data have not been selected. A destructive break has 
been selected. 

Figures 9-27 and 9-28 show a typical VTP session. Notice that in Figure 
9-27 the session is basically a login by a user onto a workstation running the 
Sun release of the Unix operating system. The user logs in and is immedi- 
ately presented with a list of current users. The user then types two keys: 1 
and s. The ls command is the Unix command for listing files. 

The not echo version of a write indicates that a particular object does not 
have to be echoed back by the other side. In the case of a host writing to a 
client, there is no need to perform an echo. In the case of a client writing 
to a host, it may or may not want to have information echoed (passwords 
are usually not echoed back on the user’s screen). 

Figure 2-28 shows a typical host command with no echo. Since the VTP 
commands are symmetrical (there is no master and client) it is necessary to 
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specify this information. In the figure, the user is typing a file called the 
termcap, which lists the capabilities of different kinds of terminals. 


Summary 


Which model of virtual terminal processing to use depends on the comput- 
ing environment. All of the models have the same basic aim—making re- 
mote applications available. 

In a local environment, strictly within a DECnet, the user can take advan- 
tage of LAT. LAT is especially useful when multiple users (or a single user 
with multiple sessions) are communicating with a single host. By multi- 
plexing and by the timer-based protocol, a significant load is taken off the 
host. 

CTERM extends the functionality of LAT by providing virtual terminal 
services in a wide-area environment. CTERM would be used when a user 
wishes to log onto a host outside the LAN. Multiple modes and support for 
a variety of characteristics make CTERM a functional method of communi- 
cating to remote Digital hosts. 

For a truly heterogeneous environment, the user would pick one of two 
protocols. VTP is used to communicate with a remote OSI host. In a 
TCP/IP environment, a similar protocol called Telnet can be used. Both 
VTP and Telnet have the attribute of being able to support a variety of dif- 
ferent terminals, although typically at a fairly low level of functionality. 
Functions like input editing, for example, are often provided at the host 
instead of the server. 

In a workstation environment, these protocols are rarely used within the 
confines of the work group. Instead of a line-by-line (or field-by-field dis- 
play) a windowing environment has more sophisticated graphical cues, in- 
cluding icons, menus, windows, and text in multiple fonts and sizes. For 
these environments, a system like the X Windows System is necessary. 

Even in the workstation environment, however, there is a need to access 
traditional applications. A workstation, or X Windows Terminal, will thus 
usually include applications like CTERM or OSI VTP for accessing remote 
hosts. 
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Messages 


Remote data access and virtual terminals both allow immediate access to 
remote systems. For many applications, however, a simple store-and-for- 
ward message is more useful. Rather than requiring the immediate atten- 
tion of all intermediate systems in a path, a store-and-forward transfer al- 
lows hosts to perform the tasks when a few cycles are free or to retry a 
failed transfer at a later time when the network might be less congested. 

A messaging system performs a store-and-forward transfer between two 
applications. The application is a user agent. The store-and-forward trans- 
fer is performed by one or more message transfer agents. The basic service 
of message delivery can be enhanced to offer more sophisticated services 
such as receipt generation on delivery. 

Applications can be traditional email programs. Applications can also be 
database programs, shareware, document processors, or spreadsheets. Data- 
base programs, for example, could use the store-and-forward service to up- 
date remote databases or to trigger electronic mail automatically when a 
certain event occurs. The DECmcc network manager, discussed in Chapter 
11, is an example of such a trigger system. When something significant 
happens on the network, the alert module can be directed to compose mail 
and send it to a list of relevant users. 

In a Digital network, there are actually two messaging systems (see Fig. 
10-1). The original messaging system was the mail-11 system, which 
worked as part of the VMS operating system. The user agent, VMSmail, 
came bundled with the operating system. 

Over time, Digital added another messaging system, known as MAILbus. 
MAILbus comes with a distributed directory to keep track of names and a 
user agent that is part of the ALL-IN-1 office automation software. 

A third messaging system is X.400. Connecting MAILbus to both mail-11 
and X.400 are gateways. X.400, being an OSI application, uses the OSI stack. 
MAILbus, being a Digital proprietary system, uses the DECnet Session Con- 
trol layer. 
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Digital MAILbus 


We start with MAILbus for historical reasons. Digital began developing the 
MAILbus while X.400 was still in the early stages. After the basic products 
became available X.400 support was added through the use of a gateway. 
The components of the MAILbus architecture are shown in Figure 10-2. 
The Message Router is the message transfer agent, using the services of 
DECnet to move messages around. Native user agents, as in the case of 
ALL-IN-1, interact directly with the Message Router. 

A user can find the correspondence between a user name and an elec- 
tronic mail address through the distributed directory. We will see that the 
distributed directory is also used by gateways as a way of storing address 
translations. 

Gateways are used to connect the native MAILbus architecture to other 
messaging systems. There are two types of gateways. A user interface gate- 
way accepts delivery of messages and translates them into some native for- 
mat for the user interface. An example of such a gateway provided by 
Digital is the one to the older VMSmail system. Digital also sells a toolkit, 
allowing an application program to interface to the Message Router. 

The other type of gateway connects multiple messaging systems. Digital 
has developed several gateways (see Fig. 10-3). The job of the gateway is to 
translate message headers and the internal content to conform to the differ- 
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ent rules. Addresses, possibly stored in the distributed directory, are also 
converted. 

The advantage of this architecture is that a single user interface can com- 
municate with a wide variety of environments. The user can use a single 
style of interacting with the computer, yet still reach users in other environ- 
ments. 

Two of the important gateways are SNADS and PROFS. SNADS, the SNA 
Distribution Services, is the message handling system used in large SNA 
networks, particularly in the DISOSS office automation product. PROFS is 
the electronic mail system for IBM’s VM/CMS operating system. 

The Ultrix gateway is also quite useful. It resides on an Ultrix node and 
interacts with the TCP/IP Simple Mail Transfer Protocol (SMTP). SMTP 
forms the basis for message exchange in most of the Internet, the loose 
collection of wide-area networks that includes NSFnet and several other re- 
search networks. The Ultrix gateway thus allows DECnet users to have ac- 
cess to a much wider messaging environment. 

The fax gateway is a one-way gateway. This software, using a fax card 
built onto a processor on the network, allows the user to send a mail mes- 
sage in facsimile form. The fax gateway can receive messages but cannot 
distribute them to individual users. Instead, the gateway prints (or stores) 
all incoming messages. 

Digital also has an X.400 gateway, which allows X.400 nodes to send mail 
messages to Digital nodes. Although this is not a native X.400 network, it 
does allow the Digital user, during a transition period, to access a wider 
X.400 environment. The X.400 capabilities are important because they form 
the basis for many public national electronic mail networks and for the 
interconnectivity products of a large number of vendors. 


X.400 


X.400 structures a collection of message transfer agents and user agents into 
a management domain—a collection of resources under a single administra- 
tion (see Fig. 10-4). 

A domain maintained by an International Telecommunications Union 
(ITU) member (or registered private member) is an Administration Manage- 
ment Domain (ADMD). All other domains are Private Management Do- 
mains (PRMD). 

The PRMD may be connected to multiple ADMDs, but for the purpose of 
any one message the PRMD is connected to a single ADMD. Routing for a 
PRMD consists of giving the message to the ADMD. Routing for the ADMD 
is simple for a directly connected domain. For further routing decisions, 
the process is outside of the specification, but note that a domain can easily 
be “directly” connected to another through the use of the OSI Session, 
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Transport, and Network layers. The X.500 directory is used to find the ad- 
dress of a relevant domain. 

Figure 10-5 shows the components that make up an X.400 environment. 
The main components are the user agent and the message transfer agent. 
The user agent prepares the message and the message transfer agents move 
messages. 

The message store is a staging point that picks up messages from the 
message transfer system and holds them for the user. The message store 
appears as a user agent to the message transfer agent: It accepts delivery of 
messages and holds them for the user. In addition, the user agent can sub- 
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mit messages to the message store, which then hands them off to the mes- 
sage transfer agent. An example of this scenario is a PC (the user agent) 
and a VAX operating as the post office (the message store). Message stores 
can be simple stores, as the name implies, but can also include services 
such as autoforwarding on behalf of a user. 

The access unit is a gateway to another message-handling environment. 
X.400 defines access units for interconnection to telex, postal delivery, and a 
few other environments. The Digital X.400 gateway is an example of an 
access unit. 

X.400 breaks a message up into three parts (see Fig. 10-6). Each message 
has a header, put in by the message transfer system. The rest of the mes- 
sage is considered data by the message transfer system. User agents com- 
patible with the Interpersonal Messaging Service (IPMS) are able to add 
further structure to the message. This layer, similar to an upper-level proto- 
col, also consists of a header and a body. 
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A user agent in X.400 is known by an originator/recipient address (O/R 
Address). This user could be an individual user or a distribution list. As 
with network-layer addressing, each user must have a unique address. As 
with the OSI network addressing standards, a variety of different formats 
are defined (see Fig. 10-7). 

For each of the formats, different elements can be used to identify a user. 
Some elements are mandatory; others are conditional—their use is up to a 
particular domain. For the postal address, for example, the country name 
and postal code are required elements. The name of the physical delivery 
service is optional—in the United States this information might specify Fed- 
eral Express, UPS, or even the postal service. In countries with a single 
delivery service, the field wouldn’t be necessary. 


IPMS 


The Interpersonal Messaging Service (IPMS) is a subclass of user agents. It 
defines a further structure to a message over that defined by the message 
transfer system. Instead of arbitrary data, the message is structured as a 
header and a set of body parts. 
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The functions provided by the IPMS are known as elements of service. 
As with the address format, the IPMS includes a variety of different ele- 
ments. Some elements are considered basic, and are part of every imple- 
mentation (see Fig. 10-8). 

A basic element of service is a’‘content type indication. The content type 
indication is a field in the IPMS header that indicates what the content 
looks like—one body part might be a fax image, another might have plain 
text. 

In addition to the structure of the message, the IPMS includes notifica- 
tions. The message transfer service gives delivery and nondelivery notifica- 
tions, indicating whether the message was transferred to a user agent. The 
IPMS adds a further service with receipts and nonreceipts that indicate 
when the message was read. There are many optional elements defined in 
the IPMS. If supported, they typically consist of a field in the IPMS header. 
Figure 10-9 shows the different services offered. The services are catego- 
rized as being provided on the origination or reception of a message. For 
each of these categories, services are further categorized as being essential 
or additional. An essential element is one that must be provided by the 
IPMS, but the user does not have to choose it on a particular message. An 
additional element is one that a particular implementation or management 
domain may choose not to provide. An example of an additional element is 
the additional physical rendition, allowing the user to have a copy of the 
message printed. This is optional on both sides. 

The autoforwarded indication is an example of an element that is addi- 
tional for the message sender: There is no requirement that you be notified 
if a message you sent was automatically forwarded to another user. On the 
other hand, this element is considered essential on reception: A user receiv- 
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ing a message should be able to find out if the message was in fact autofor- 
warded. 

Several elements are not available on a per-message basis but must be 
contracted for (see Fig. 10-10). For example, the message transfer system 
can hold a message when it receives it and deliver it later. Implicit conver- 
sion, redirection, restricted delivery, and services of this sort require addi- 
tional resources within the message transfer system. 

Figures 10-8 through 10-10 show the list of possible IPMS elements in 
(close to) its entirety, thereby demonstrating the richness of the X.400 mes- 
saging environment. Note that not all user interfaces will know what to do 
with all these elements. The underlying IPMS supports the functions, but 
the user interface will typically ignore additional elements. For this reason, 
a user may occasionally examine a message with a plain ASCII editor to see 
if there are additional elements included but not shown to the user. 
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Message Transfer Agent 
There are three types of objects in the message transfer system: 


® messages 
e probes 
* reports 


A probe goes from one user to the message transfer agent that would de- 
liver a message to another user, and is used to test connectivity. A report is 
an object sent from the message transfer system to a user. Each report 
concerns .a message or probe. 

Figures 10-11 and 10-12 show the structure of the message transfer agent 
modules. Incoming messages are delivered to either the main or report 
modules, which results in either a message, report, or probe being sent out. 
The main module provides a variety of different functions. One is splitting, 
which takes a single message with multiple addressees and splits it into 
several messages. This occurs when there is a split in routes. One recipient 
is located in one direction; other users in other directions. Joining is an 
optional step to join multiple messages headed for the same place. For ex- 
ample, 10 nondelivery messages’ going from a distribution list to a single 
address that originated the failed message might be joined. 

Name resolution, distribution list expansion, redirection, and conversion 
are optional services. Nondelivery is an example of a message sent back to 
a user when a message is discarded, usually because the destination user or 
domain is unknown. Finally, there is the question of routing—selecting 
which message transfer agent gets the message next. How information gets 
routed is up to a specific environment. Presumably, MTAs will use a hierar- 
chical routing system: All unknown messages go to a “root” server, which is 
connected to other management domains. 

Figure 10-13 shows the types of services offered by message transfer 
agents. Again, they are split up into basic elements (always provided), es- 
sential elements (available but not required), and additional elements (op- 
tional per implementation). Most of these elements of service are 
transmitted in the message transfer agent header. For example, a user 
could specify that an alternative recipient is allowed (or not allowed). De- 
ferred delivery allows a message to be submitted to the message transfer 
system with the proviso that it not be delivered before a specific time. 

The deferred delivery cancellation is an element that shows that not all 
requests are always granted. A user can send a message with deferred de- 
livery, say a press release announcing DECnet Phase V for VMS. Once the 
message is sent, it stays in a queue someplace in the message transfer sys- 
tem awaiting delivery. The originator may then decide, perhaps because of 
technical difficulties, to delay the announcement and sends out a deferred 
delivery cancellation. There is no guarantee the deferred delivery cancella- 
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tion, if issued close to the time of delivery stated on the original message, 
will catch up with the deferred delivery message in time to cancel the origi- 
nal message. 

Figure 10-14 shows a typical X.400 message exchange. First, the presenta- 
tion-level connection is made and accepted. Next, the session layer activity 
start is sent. Then, the X.400 P2 protocol is invoked. P2 is a code for the 
interpersonal messaging service. Notice that this particular message is us- 
ing the 1984 version of the X.400 protocols. 

Figure 10-15 shows the P1 protocol (MTA to MTA) in more depth. This 
particular message is a delivery report. The message indicates a message 
identifier (the message Protocol Data Unit ID), as well as the originator of 
the report. It then has trace information indicating when the message 
reached different locations. 

In the content section is the identification of the original message. The 
message was sent from the country United States, the administration man- 
agement domain ATTMail, the private management domain Retix, and 
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from a particular user ID. The message also indicates that the message was 
received by a user with the personal name Elena Seifrid and was delivered 
July 26, 1988. 

Figure 10-16 shows the IPMS layered inside of the message transfer proto- 
col. The MTA header includes the originator of the message and the basic 
information type, IA5text being a basic text message. The content type indi- 
cates this is an IPMS message instead of some private protocol. 

The message also includes various per-message flags. Notice that the dis- 
close recipients flag is on, allowing each user to know about the other users. 
No alternative recipient is allowed: if the message cannot be delivered it is 
dropped. 

Next, we see information for the two recipients of the message, including 
an address and flags indicating basic reports are requested. This is followed 
by trace information, indicating where the message has been so far. We see 
that the message appears to have been relayed at least once by a message 
transfer agent called VAX. 
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After all this information, we see the IPMS header. The message has a 
unique ID, an originator, and two primary recipients. The reply requested 
flag is set to false. Even if the flag were set to true, there is no way we 
could have forced our two users to respond. The body of the message, con- 
sisting of a single body part, is composed of IA5Text. The message begins 
“Testing for Andre” and has an additional 1720 bytes. 


Distribution Lists 


A distribution list is a list of individual O/R addresses or other distribution 
lists. In addition to its members, a distribution list has several other prop- 
erties: 


¢ The submit permission says which users and distribution lists can 
make use of this list. 

¢ The expansion point is the O/R address of the list, the place where it is 
translated into its constituent members. 

¢ The owner of the list. 


Somebody sending mail to a destination does not have to know that the 
destination address is a distribution list. Remember, however, that message 
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charges can rapidly mount if one message turns into 100. One option in 
X.400 is to prohibit distribution list expansion. 

The expansion point for a distribution list is a message transfer agent 
(since the user does not exist). The expansion point will “burst” the mes- 
sage into several pieces, sending them back out the message transfer system 
(see Fig. 10-17). Any charges for the activity would typically go back to the 
original user (although it is possible they would be incurred by the owner 
of the distribution list). 

Distribution lists can be nested. When a nested distribution list is ex- 
panded, the ID of the parent distribution list, not the originator of the mes- 
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type = 2 <P2> 
UA content id = 889726 14:53:53 
Priority = 2 CUrgent> 
Per message flag ce 
Lictsieldie:«-2;6 Disclose recipients 
Conversion prohibited 
No alternate recipient alloued 
No content return request 


rd oe eteters 


6B. Ses 
oo e@ osee 
Recipient info: 
Recipient: “C=US“ADMD= —ATIMAIL“PRMD=ret ix“O=aun“PN=donoghue. barbara 
Extension identifier 
Per recipient flag = as 
1... .... = responsibility flag on 
-@1. .... = basic report request 
---@ 1... = basic user report request 
Recipient info: 
Recipient: /“C=US“ADMD=ATTMAIL/PRMD=retix/O=sun’PN=seifrid.elena/ 
Extension identifier = 2 
Per recipient flag = D@ 
1... .... = responsibility flag on 
-1@. .... = confirmed report request 
---1 6... = confirmed user report request 
Trace information: 
Global domain identifier: /C=US/“ADMD=ATTMAIL/PRMD=RETIX/ 
Arrival = 26 Jul 1988 14:53:58-06708 
Action = @ (Relayed> 
Internal trace info: 
MTA name = VAX 
Arrival = 26 Jul 1988 14:53:58-0700 
Action = @ CRelayed> 


x.400 Interpersonal Messaging Protocol €P2Z)> 


UAPDU type = Interpersonal Message Clength = indefinite» 
Heading: 
IP message id: /“C=US/“ADMD=ATTMAIL/PRMD=RETIX/“0=VAX/PN=SEIFRID. ELENA. 
886726 14:53:53 
Originator: /C=US“ADMD=ATTMAIL“PRMD=ret ix/0=sun/PN=Seifrid.Elena.D/~ 
Primary recipient: 
O/“R Descriptor: ~C=US~“ADMD=ATTMAIL/PRMD=ret ix/“0=sun/’PN=donoghue. bar 
Reply request = FALSE 
Primary recipient: 
O“R Descriptor: /C=US“ADMD=ATTMAIL/PRMD=retix/0=sun/PN=seifrid.elen 
Subject = Test message on Retix X.480 netuork 
Body: 
IASText = "Testing for Andre...." 
Unidentified [1726 bytes] 


Frame 39 of 171 
Use 7 on to select windous 


+ 2 Set Omer Aeley a) 6bDisplyB? Prev 8 Next 16 Neu 
Help mark out one options frame frame capture 
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sage, is used to check whether expansion is allowed. A potential problem 
with distribution lists is recursion. To prevent this, a message includes a 
chain of the distribution lists used to get it to this point. The expander 
checks the list to detect any recursion. 

Notifications regarding a distribution list can come from the distribution 
list expansion point (e.g., submit permission denied) or the ultimate desti- 
nation (e.g., message undeliverable). 


Summary 


In X.400 we see a rich messaging environment. What makes X.400 so sig- 
nificant is the large number of computer vendors and national telecommu- 
nications suppliers who have already implemented the standard. The large 
number of options available, and the support for access units, message 
stores, and other capabilities mean that it will be a while before the limits 
of X.400 are reached. X.400 promises to be one of the foundation services in 
an OSI environment. 


; Messages 333 
————— 


Digital uses the approach that many vendors have in supporting X.400— 
an access unit to their native messaging system instead of native X.400 sup- 
port. The MAILbus architecture is a DECnet application. The X.400 
Gateway for the Message Router moves messages out of the MAILbus envi- 
ronment and into X.400. 
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Management 


Management of Phase V conforms to the Enterprise Management Architec- 
ture (EMA), a cross-architectural model of how to manage distributed sys- 
tem and its components. As we have seen, DECnet does not operate in a 
vacuum—other components such as LAT, the extended Ethernet, T-1 and 
fractional T-1 hardware, all require management. 

We can treat a distributed network as a series of hardware and software 
components. Each of these components is an entity. We structure the enti- 
ties in a tree to make management easier. For example, in Phase V the top 
of the tree is the node, and subentities include items such as routing and 
transport modules. The routing entity will likewise have subentities, such 
as circuits and adjacencies. 

Network management has been broken up by the ISO into a variety of 
functional areas. These areas include 


° configuration management 
¢ fault management 

* performance management 
* accounting management 

* security 


Configuration management allows the network manager to install and 
control a particular module. An example of configuration management is 
to add manual routing information to the DECnet routing module. Fault 
management is the detection of faults, their isolation, and, it is hoped, their 
repair or removal. 

Performance management lets the manager tune the network, as in the 
case of increasing throughput in the transport layer by adjusting maximum 
window sizes. In LAT, the manager might set the timer on the master to 
reflect the longer delays in a wide-area extended Ethernet. 

Accounting management lets the manager figure out what happened on 
the network. We might want to know which nodes used the Ethernet, or 
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which users used a particular module, or how many bytes were sent over a 
particular line. 

Three other areas—security, names, and applications—are not strictly net- 
work management topics but have a lot of overlap. Security is an issue that 
is present in all layers of the operational network. Security is also impor- 
tant to prevent unauthorized persons from managing the network. Name 
management is a question of data administration but quickly impacts the 
ability of the manager to find managed objects. Management of applica- 
tions includes database managers, remote file access protocols, or distrib- 
uted transactions management services, or even an operating system. 


Management Model 


We begin with the question of local management of an entity. Every entity 
provides a service interface; that is, the way in which a user of the module 
takes advantage of its services. The transport module, for example, uses the 
service interface of the routing module. The routing module, in turn, uses 
the service interface of the subnetwork modules. 

In addition to the service interface, every module presents a local man- 
agement interface, usually a set of implementation-dependent system calls. 
The performance of the network management functions is done by a man- 
agement agent. 

Figure 11-1 shows the structure of network management on a single 
node. The director is the program that performs network management 
functions. When a management directive is issued, it is done using the 
local management interface. Since there are several modules, the directive 
is intercepted by an agent directive dispatcher, which moves the directive 
to the agent which actually performs the task. Another user of the local 
management interface is the agent access module; it is a network-accessible 
module that performs directives on behalf of remote directors. 

Figure 11-2 shows the framework for management. We start with the 
network manager, usually a human being but occasionally a program or 
batch file. The manager uses a program called the Network Control Lan- 
guage (NCL), which is an example of a director. NCL in turn submits re 
quests to the local management interface, which moves them to the node 
and its subentities. 

A special kind of director is the initialization director, used when the 
node initializes. This initialization director makes use of scripts, which set 
initial parameters. This script allows a node and its subentities to have the 
appropriate parameters set before they begin operation. 

In addition to accepting directives, an entity periodically generates re- 
ports known as events. These reports, such as error reports or changes in 
operational status, are sent to sinks where they are logged. The protocol 
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used to send reports over the network is the Common Management Infor- 
mation Protocol (CMIP). The event dispatcher on a node uses CMIP to send 
the event report to a CMIP event logger program known as a listener. 

The CMIP event logging protocol is based on Digital’s Management Event 
Notification (MEN) protocol. The other major CMIP protocol is the Manage- 
ment Information Control and Exchange protocol (MICE). The combination 
of MICE and MEN allows a remote node to define which operations should 
be performed (including which events are desired), and to receive asynchro- 
nous event reports. CMIP is the basis for allowing a remote director to 
control a Phase V node. 

Figure 11-3 shows the structure of a Phase V node. The node’s 
startup/shutdown module is used to set up the initialization director, which 
in turn feeds the initial management directives into the node. The node 
structure also includes a name keeper and address module, responsible for 
maintaining the network address. The CMIP/MICE module receives remote 
requests for network management. 

When a CMIP request is received, the request goes to the agent directive 
dispatcher, which is responsible for getting the directive to the agent for 
that particular module. CMIP also uses the functional network modules to 
communicate requests over the network. CMIP is a user of the DNA Ses- 
sion Control layer. Finally, the UID and time services are used by both 
network management and functional network modules. 

The question of what operations can actually be performed on a module 
are beyond the scope of the network management architecture. The defini- 
tion of these tasks is up to the individual module architecture. The net- 
work management architecture provides & systematic way for defining 
these management functions and for making the management functions 
available in a distributed environment. 

The primary way in which a module makes its management capabilities 
known is through a registry, a central repository of management definitions 
maintained by Digital. When a Digital architect works out a new module, 
the definition of the operations and the information maintained by the 
module are put into the registry that integrates the naming schemes of dif- 
ferent modules into a unified namespace. 

Particularly important is how an entity fits into the naming scheme. At 
the top of the namespace are global entities, such as the DNA Phase V node. 
As in the DNA Naming Service, an entity full name is the concatenation of a 
set of simple name fragments. For network management purposes, each 
name fragment has two pieces, a class name and an instance identifier. 
The class name is required to be unique at least within the child classes and 
attributes of its parent. Thus a bridge can have a child entity circuit, as can 
a routing layer. On a Phase V node, we might see two entities, DNA Rout- 
ing and IP (for the TCP/IP routing layer). Both have child entities named 


Management 341 








__Statuphutdown Module Module 


Name Address CMIP/ Initialization 
Keeper Module MICE Director 


Functional Agent Directive 
Network Modules Dispatcher 









Maintenance 





11-3 DEC Network Management Node Structure 
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“circuit,” which may in fact end up with both circuits sharing the same 
physical hardware. 

The instance identifier must also be unique within a particular location 
in the tree. Thus, two circuits of a routing module must have different 
names. It is possible to have alternative identifiers for a particular instance, 
but one is labeled as the primary identifier and shows up in the event re- 
ports. 

An example of a name is: 


Node DigitalPR.XENOPHOBE ROUTING CIRCUIT UNA-O 


Node is a global entity, and the node DigitalPR.XENOPHOBE (which hap- 
pens to be a DNS Full Name) is the instance. Routing is an example of an 
entity that does not need an instance identifier, since there is by definition 
only one per node. Finally, we have the circuit subentity class with the 
identifier UNA-O. 

The global entity (of which node is the only one discussed here) has the 
special characteristic of providing an agent (such as a CMIP listener) so it 
can be remotely managed. Each global entity has a DNS full name. The 
global entity is then responsible for distributing incoming directives to its 
subentities. 

In addition to a name, every entity has a series of attributes that are 
defined. There are three types of attributes: 
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e identifiers (counters) 
e characteristics 
e status 


The identifiers are attributes such as names and addresses. Characteristics 
affect the behavior of the entity. Status attributes are used to monitor the 
behavior of an object. 

We can take sets of attributes and put them into attribute groups, such as 
the groups “summary” (for high-level summary information) or “critical” 
(for attributes reflecting critical network functions). Attribute groups allow 
the network manager to refer to collections of information without specify- 
ing each individual attribute in the class. 

In addition to defining an entity via a name and attributes, the architect 
defines events and directives. The events contain significant information a 
network manager may want to see periodically. Once a particular event is 
described, the manager uses CMIP to specify that he or she is interested in 
having reports of that event dispatched to a particular event sink. 

Directives are the types of commands to which a management entity will 
respond. Directives are always in response to a command from a director. 
If an entity feels it should do something, it would send an event report to 
the director, which would respond, if appropriate, with a directive. 


Network Control Language 


NCL is an example of a director operating in a command line mode. NCL is 
a simple user interface. In the DECmcc section, we will see examples of 
more sophisticated directors, such as graphically oriented windowing appli- 
cations. 

NCL commands are translated into network-based requests, such as CMIP 
management directives or commands to the DNA Naming Service. Rather 
than being a network protocol, NCL is thus a specification of how entities, 
operations, and data are requested by the user and subsequently displayed. 

NCL is based on two types of commands. Database commands are used 
to examine and modify the attributes of an entity. Action commands are 
used to manipulate the entity itself. The syntax of NCL allows multiple 
attributes (data maintained by an entity) and arguments (the way an entity 
performs an action) to be applied to an entity at once. Action commands 
are a request/response protocol and are always acknowledged. 

The initial operation is for the user to type a network management com- 
mand. The NCL module then performs a lexical parse on the command 
and separates the letters into white space, comments, command termina- 
tors, and tokens. A token is the basic unit of operation on which the parser 
works. 


Management 343 


Next, the parser scans the tokens for any locally stored aliases (such as 
abbreviations for node names). The parser makes substitutions, then res- 
cans until no more substitutions are made. Finally, the parser makes a 
syntactical parse, trying to figure what each token means and what the col- 
lection of tokens means. The architecture (although not necessarily all of 
the products) is extensible, allowing the manager to add new entities, attrib- 
utes, or other operations to the language. 

The basic command consists of a verb, an entity, and attributes. The 
command may optionally have an argument and a prepositional clause. An 
example of a command is the remove command. To remove an instance of 
a routing module, the user would type: 


remove node dec.pr.xenophobe routing 


Prepositional clauses help to refine the command. An example of a 
prepositional clause is access control information. Before CMIP (and the 
target node) will carry out a function, the user must be authenticated. A 
prepositional clause would carry in the user’s account and password infor- 
mation. If proxy logins are being used, this information is not needed and 
the prepositional clause can be omitted. 

Another type of prepositional clause is the entity filter, used to specify 
which entities are the target; for example, 


show node * with type=endsystem 


Node * is a wildcard specification for an entity, here referring to all nodes 
on the network. The with type clause selects all end systems. 

In addition to specifying the format of a command and how it is parsed, 
NCL defines how the results are to be displayed or how errors are to be 
shown. The display of a result consists of a header and the data. The 
header contains the name of the operation, the target entity, any filters, and 
a time stamp. The data display can be the results of the CMIP, local NCL, 
or DNS commands. 

An example of a command and the resulting display is 


NCL> SHOW NODE .DigitalENG.Siva ROUTING CIRCUIT UNA-O ALL - 
_NCL> CHARACTERISTICS 


NODE .dec.eng.siva ROUTING CIRCUIT UNA-O 
AT 12-AUG-1987:14:32 

CHARACTERISTICS = 

CREATE TIME = 3-MAR-1987:08:03 

TYPE = ETHERNET 

TEMPLATE NAME = 

LINK NAME = 

HELLO-TIMER = 60 
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L1 COST = 20 

L2 COST = 20 
QUEUE LIMIT = 2 
MAX ROUTERS = 32 


ROUTER PRIORITY = 64 

MANUAL DL BLOCKSIZE = 1024 

MULTICAST QUOTA = 4 

TRANSIT ACCESS = INTERNAL DNA 

EXPLICIT RECEIVE VERIFY = TRUE 

MANUAL L2 ONLY = FALSE 

MANUAL DESIGNATED ROUTER = 00-00-00-00-00-00 


An example of an error display is 


NCL> SET NODE .DigitalENG.Siva ROUTING CIRCUIT UNA-O - 
_NCL> HELLO-TIMER = 60, MULTICAST QUOTA = 4 


NODE .dec.eng.siva ROUTING CIRCUIT UNA-O 
UID 1987-08-09-17:32:00 120002 AA-00-04-01-AC-DC 
AT 12-AUG-1987:14:32 
FAILED IN SET OF 
MULTICAST QUOTA 
DUE TO 
CONSTRAINT VIOLATION 
NCL> 


CMIP 


Whereas NCL defines how commands are entered and displayed, CMIP de- 
fines how they are moved across the network. By providing a common 
definition of network management requests, CMIP allows a director from 
one vendor to manage an entity from another. 

The Digital implementation of CMIP uses the DNA Session Control layer 
to set up a session between a director (the CMIP requestor) and a managed 
node (the CMIP listener). Note that the OSI Session Control layer is not 
being used, which means Digital CMIP may not necessarily interact with 
other vendors’ CMIP implementations. The incompatibility is only at the 
Session Control layer, since the DNA Session Control layer will then have a 
choice of OSI TP4 or NSP transport protocols. 

The association between the two CMIP-speaking processes is established 
using the CMIP associate message (see Fig. 11-4). Access control for this 
session is up to the Session Control layer. The Session Control layer would 
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either use explicit access control (a username and password) or would in- 
voke a proxy login. 

Once a session is set up, the CMIP exchange consists of a series of invoke 
operation messages and their results. The invoke command (see Fig. 11-5) 
has seven basic types of operations. The event report operation requests 
that certain events be sent. The linked reply is used to indicate that this 
command is linked to another one. 

The basic CMIP operations are get, set, action, add, and remove. Each 
entity’s management structure is typically worked into those basic five com- 
mands. After the command is a set of arguments (see Fig. 11-6) that further 
specify how the command is to be interpreted. An argument always has an 
entity class, instance, and (for DEC) the UID of the entity. Then, depending 
on what type of operation, there is a set of operation-specific arguments. 
For an event report, for example, the argument specifies what type of event, 
what time, and any event-specific information. For the set operation, there 
is synchronization information (to prevent two directors from stepping on 
each other), an entity filter, and a list of specific attributes. 
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After the operation is performed, the results are put into a return results 
message (see Fig. 11-7). The result format is dependent on the specific type 
of operation, but it usually includes at least the resulting entity specification 


and any attribute values. 


If the command cannot be properly executed, the return error message is 
sent back (see Fig. 11-8). The errors are split into five general classes, with 


specific numbers assigned within each class of errors. 


General problems 


such as protocol errors apply to all operations. Invoke problems such as a 
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duplicate operation invocation are the result of a request. There can even 
be problems in returning an error (as in the case of an error report being 
sent with an unrecognized invocation ID). Following the error number is a 
series of error parameters that further define the error. 

Figures 11-9 and 11-10 show a typical example of a request/result ex- 
change using CMIP. The request and the result share the invocation of ID 
of 1234. The operation is a get operation, which specifies an entity class 
and an instance. The entity class is a fully specified example of the class 
name, resolving down to a particular circuit. The request specifies three 
attributes—the circuit type, a template name, and a hello time. 

The results show that the circuit type is an 802.3 Ethernet circuit, with a 
hello time of 600 seconds (hello messages are sent every 10 minutes). The 
template name is used as a method of setting different instances of an en- 
tity the same way. The result includes the state of the entity as well as the 
other requested attributes. A director should be prepared to receive addi- 
tional attributes in a result on top of those initially requested. 

Figures 11-11 and 11-12 show an example of CMIP operating over a 
TCP/IP-based link (CMIP over TCP/IP is known as CMOT). Again, the get 
command is being used to get the current status of a module, in this case 
the transport layer TCP module. The result of the operation shows a vari- 
ety of different requested counters. The number of passive TCP opened 
was 46, with no resets and no failed open attempts. 

Figure 11-13 shows a typical CMIP session. The session begins with the 
node Bridge requesting the system ID from another node. The bridge then 
sends a request for TCP information to three different nodes—another 
Bridge, an U-B, and one Hewlett-Packard. Next, the node sends a request 
for the TCP/IP network layer (IP) information. 

As can be seen, CMIP allows a network director to request information 
from several different nodes on the network. The node Bridge could be an 
automated program that collects periodic information off the network and 
puts it into a database. The database can then be examined by the manager 
at a later time. 

We will see that DECmcc is an example of such an automated director. 
The user can submit a request asking for certain information to be collected 
periodically. DECmcc will store the request and, as each period arrives, 
send out the proper management directives. 


Event Logging 


The event logging architecture defines a framework for the definition of 
how to record, transmit, filter, and process events. The semantics of spe 
cific events is up to the individual modules. Event logging uses the CMIP 
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Delta T——DST————_——SRC. 
1 Broadcast ¢Sun @1S5ABC RWHO HOST=falcon 

52 SEY Gee we) @1A982+Bridge@11AC3 CMIP Get sysID 
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61 6.3988 Bridge@11AC3+U-B 681A9G6Z Got tcpActiveOpens ... tcpR 
64 6.8825 H-P O62ZFAAE+Bridge@11AC3 Get tcpActiveOpens ... tcpR 
78 @.2442 Bridge@11AC3+H-P @2ZFAAE Got tcpActiveOpens ... tcpR 
81 6.9384 Bridge@@DBF@+Bridge@11AC3 Get tcpActiveOpens ... tcpR 
82 6.6478 Bridge@11AC3+BridgeB@DBF@ Got tcpActiveOpens ... tcpR 
84 1.1273 Bridge@@DDD8+Bridge@11ACc3 Get tcpActiveOpens ... tcpR 
8S @.8471 Bridge@11AC3+Bridge@eDDD8 Got tcpActiveOpens ... tcpR 
86 1.1238 Bridge@@DDD8+Bridge@11AC3 Get ipInReceives ... ipOutR 
88 8.8484 Bridge@11AC3+Bridge@aDDDS Got ipInReceives ... ipOutR 
92 1.1321 Bridge@@DDD8+Bridge@11AC3 Get sysID 

94 8.6371 Bridge@11AC3+BridgeB@@DDDS Got sysID = 3COM CS/Z18 SU 
36 1.1488 Bridge@@DBFG@+Bridge@11AC3 Get ipInReceives ... ipOutR 
37 6.8305 Bridge@11AC3+Bridge@ODBFa@ Got ipInReceives ... ipOutR 
101 1.1481 Bridge@@DBFO+Bridge@11AC3 Get sysID 
183 8.8372 Bridge@11AC3+BridgeB@DBFe Got sysID = 3COM CS’21@ SU 
188 1.1453 H-P 62FAAE+Bridge@11AC3 Get ipInReceives ... ipOutR 
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protocols (MEN) to get the event from the source to the sink. The compo- 
nents of this architecture (see Fig. 11-14) are 


°® event sources and sinks 
¢ Phase IV relays 

° event dispatcher 

° directors 


The sink is a named entity that supports the event logging architecture sink 
interface and CMIP. In other words, the sink specification is layered on top 
of CMIP. An event stream is a long-lived relationship between a source and 
a sink. It survives communication, process, and system failures because the 
network management system monitors the status of sinks and tries to rees- 
tablish them in the case of failures. 

Each network must have at least one sink (although a null sink would 
qualify). A hybrid Phase IV/V network must have either a Phase IV sink or 
a Phase IV event logging relay. 

The event dispatcher is a module. As such it has a management agent 
that uses the MICE protocols to respond to a request. It also has a sink 
interface to local modules to receive requests and a MEN interface to the 
network to dispatch events. 

Each event is self-describing. The event report includes 


° entity name 

° time stamp 

° UID 

° event-specific parameters 


A special type of event is the pseudoevent, which is entered into the 
stream by the event dispatcher or sink. The pseudoevent helps interpret 
the stream: It represents changes in the logging system. Examples include 


e events lost 
¢ change in filter 
e enable stream 


Pseudoevents are generated at sources and sinks. Any pseudoevent, ex- 
cept the events lost pseudoevent might be lost. Pseudoevents are dis- 
patched to the sink. They come from the sink; they go right back in. An 
example of an events lost pseudoevent, as displayed in NCL, is 


Event: EventsLost, from: Node DigitalENG.NAC.LYRE EVD 
at 1987-08-1 1-18:22:33:04-05001.02 
Number = 1] 
event UID 12345678-9012-B456-800 1-08002B033D7A 
entity VID 12345679-9012-B456-800 1-08002B033D7A 
stream UID 12345676-9012-B456-800 1-08002B033D7A 
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The sink is a generic entity. It could be a system console, a log file, or a 
flashing red light or siren. It could even be a nose on a Ken Olsen doll that 
lights up. There are three aspects of the sink that are defined in the archi- 
tecture: 


* communication with the event dispatcher 
* local sink filtering 
¢ sink service interface to read event reports 


Each event is time stamped. Remember, however, that time in DNA is an 
interval. The ordering of overlapping time intervals is indeterminate. 
Within events from a single instance of an entity, it is possible to order 
events by the midpoints of time stamps. Optionally, if a node issues more 
than one event in a single clock tick, it can add a sequence number. 


Event Filtering 


Filtering of events occurs in two places: Each outbound stream at the 
source has a filter. Additionally, each sink maintains a single filter that 
applies to all inbound streams. 

The filter is set up as a tree, which conforms to the entity hierarchy in 
Phase V. At each level of the tree, we can pass or block a particular type of 
event. We might, for example, want to block all events in a given class or to 
pass events from a specific entity but block all others. Three filters are used 
to implement this functionality—a specific filter tree, a global filter tree, 
and a catchall filter. First the specific filter tree is searched. If a value is 
matched (pass or block) the action is performed. If the value on the tree is 
ignore, the global tree is searched. Again, we look for an action. Finally, 
the catchall filter is searched. 

The ignore action is a place holder—it maintains the structure of the tree 
without causing an action. It lets us put a specific entity into that tree, but 
still have the global action apply. 

The filter interface has a test operation, allowing the manager to test a 
particular event to see if it would pass or block on the trees. There is also a 
show command to show the tree. For example, 


block instance = node NAC 
routing circuit QNA-O 
' event = adjacency 
block instance = node NAC 
routing circuit QNA-O 


event = all 
block class = routing circuit 
event = all 


block instance = node * routing * circuit * event = all 
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ET 


Flow of an Event 


An event goes through the following sequence: 


* The source entity posts the event to the dispatcher. 

¢ The dispatcher posts the event to all enabled outbound streams. 
¢ The streams filter the event. 

¢ The streams call the CMIP event report sender. 

° The CMIP event report receiver gets the event, calls the sink. 

¢ The sink filters the event. 

¢ The sink queues the event. 

° The sink client application reads the event. 

° The doll’s nose lights up. 


To maintain compatibility with Phase IV domains, an event may option- 
ally go through a Phase IV relay. The Phase IV relay is an entity on the 
Phase V node and appears to the Phase IV nodes as a monitor, console, or 
logging sink. The relay converts Phase IV events to Phase V by encapsulat- 
ing them. 

Phase V is similar to the Phase IV model but with a generic and arbitrary 
number of sinks (IV only had the three predefined types). Phase V event 
logging also added filtering at the event dispatcher and the sink, as well as 
the concepts of pseudoevents. 


EMA and DECmcc 


The Enterprise Management Architecture defines a model for building ex- 
tensible management systems (directors) of which DECmcc is one. Manage- 
ment is provided by plug-and-play modules. DECmcc has three pieces (see 
Fig. 11-15): 


¢ The DECmcc kernel provides the framework routines that allow man- 
agement modules to exist as different processes on the same or differ- 
ent systems. 

¢ The management information repository contains structured informa- 
tion about entity classes, information about specific entities (entity at- 
tribute data) and private information such as historical data, for each of 
the management modules. 

* Management modules provide one of the three types of services: func- 
tion, presentation, or access. 


Examples of presentation modules are DECwindows or the command 
line interface, known as the Forms and Command Line (FCL) Presentation 
Module. In addition, presentation modules might include report generators 
or a 3270 terminal forms interface. 
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11-15 DECmcc Module Structure 


Function modules do things like record historical data, manage network 
configurations, and generate alarms used to notify users of important 
events. They take the information received from access modules and add 
value to that information. Function modules often provide generic func- 
tions that apply to a variety of access modules. 

Access modules are specific to a management environment, TCP/IP, Eth- 
ernet, DECnet, or a voice/data switch. Function modules provide more ge- 
neric functions like keeping track of historical data, relying on the access 
modules to get that data. 

Four important interfaces are not specified in DECmcc: 


* presentation module to the presentation device 

° access module to its entities 

° kernel to the operating system (i.e., RMS versus Rdb for disk access) 

¢ kernel-to-kernel synchronization for distribution of the DECmcc kernel 
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DECmcc specifies the interface between a management module and the 
kernel, which in turn provides access to the operating system and to man- 
aged entities and other management modules. DECmcc is extensible. This 
means that a given management module may or may not be present at any 
given time. When a management module is added to the system, it is en- 
rolled. 

The kernel provides five categories of routines: 


¢ framework routines 

* common routines 

¢ information manager and dispatcher 
¢ dictionary routines 

¢ dispatch enrollment 


The framework routines are a way of sharing a single kernel among multi- 
ple processes. The multithreaded kernel provides efficient operation be- 
cause blocks of code can be run in parallel in the same virtual address 
space. This simplifies asynchronous processing. 

Three types of framework routines are provided to support the mul- 
tithreaded environment: 


e thread creation and deletion 
° interthread synchronization 
° interthread communication 


The kernel common routines are used for encoding and utility operations 
such as time conversion. 

The information and dispatcher calls are the portion of the kernel that 
handles the intercomponent procedure calls used to access other manage- 
ment modules. This is provided at two levels. The mcc_call_function serv- 
ices access a value-added service, typically offered by a function module. 
The mcc_call_access accesses a primitive service, typically offered by an ac- 
cess module (see Fig. 11-16). 

The information manager provides access to attribute data in DECmcc 
and handles the scheduling. The dispatcher does the actual call and han- 
dles the results. 

The information manager handles most of the scheduling task. For ex- 
ample, if a call refers to historical data, the information manager will try to 
get the information out of the database before passing the request to the 
management module. If the time for a request is in the future, the infor- 
mation manager will block the request. If time is a series of distinct time 
instances, the information manager will break the single call up into a se 


ries of distinct calls. This means the management module only sees indi- 
vidual calls. 
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11-16 The DECmcc Call Interface 
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The dispatcher processes the verb, entity, and attribute parameters of a 
call and chooses the appropriate procedure using a dispatch table. The dis- 
patch table is a registry of which modules are accepting which types of 
requests. The function dispatch table is first searched by verb and attrib- 
ute, then by entity. The access dispatch table is optimized for entities: Enti- 
ties are searched first, then verbs and attributes. 

Procedures in two modules cannot call each other directly because they 
do not know the virtual address of the called procedure nor which module 
is handling a particular request. The kernel does the dispatching, insulat- 
ing modules from each other. 

Dispatching is based on a verb, entity, attribute tuple (known in the docu- 
mentation as a <V,E,A> tuple). When a management module enrolls itself, it 
provides a series of these tuples, along with the associated procedure to call. 
These tuples might be specified using wildcards. For example, the asterisk 
(*) specifies all entities in a class, and the trailing ellipsis (...) specifies all 
subentities in a tree. 

Calls are sent down in a request/response scenario. To relate multiple 
sets of these calls, a context handle is used to inform the mcc_call interface 
that the present call is related to previous ones. Multiple call sets are used 
in a variety of instances. For example, the information manager may re- 
turn multiple time sequences; a management information routine may re- 
turn information of requests over a range of past times; or, with 
wildcarding within subentities, multiple access and function modules may 
handle a single call, returning multiple pieces of information. 


<V,E,A> Tuples 


Any calls to DECmcc use the same format, which consists of the following 
components: 


° verb 

* input_entity 

° attribute 

° time specifier 

¢ input additional data 

* input additional qualifications 


The verb, entity, attribute tuple is encoded as a set of internal DECmcc 
codes. The attribute is only present on nonaction directives such as set or 
show. The additional data and qualifications are all encoded as indicator, 
length, value (ILV) sets. The output from the call is 


° output parameter 
° time stamp 
* output entity 
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There is also a shared (input/output) parameter known as the context han- 
dle and a Condition Values Returned (CVR) indicator that shows whether 
the call had success or failure. 


Processing Wildcards 


The presentation manager will try to expand global entity wildcards before 
processing commands. It does this by calling the Domain Function Module. 
This means a different call would be sent down for, say, database manage- 
ment and network node management. 

For lower levels of entity wildcards, the presentation module has the op- 
tion of calling the configuration function module for a list of all entities 
that match. If there is no configuration module present, the presentation 
module can send the request down and let the appropriate function mod- 
ules handle the request. 

When each management module enrolls, it specifies what level of wild- 
carding it is willing to accept: 


° local entity classes 

° full global entity instances 
¢ full local entity instances 
¢ partial entity instances 


Figure 11-17 shows an example of the processing of a call. The user types 
in a command using NCL. The Forms and Command Line (FCL) module 
takes that call and turns it into an mcc_call_function call. The dispatcher, 
using the function dispatch table, sends the call down to the control func- 
tion module. The control function module takes the call and formulates it 
into an mcc_call_access call. Note that the function module, by using the 
dictionary, could have broken the call up into several access calls, one for 
each of several different access modules. 

In this case, however, the call goes straight to the DECnet Phase IV access 
module, which uses the Network and Information Control Exchange (NICE) 
protocol. NICE serves the same purpose in Phase IV that CMIP does in 
Phase V—the network protocol to allow a remote director to communicate 
with an entity. 

Once the NICE call is formulated, it leaves the boundary of DECmcc and 
enters the actual network being managed. Presumably, the Phase IV net- 
work uses NSP and DNA Session Control to set up a virtual circuit to the 
managed entity, NODE4. Once the response comes back, the access module 
sends up the first portion of the response. The returned information in- 
cludes a context handle that indicates more information is available. The 
presentation module will make repeated calls with the context handle speci- 
fied until no more information is available. 
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MCC> SHOW NODE4 updike CIRCUIT * 
ALL COUNTERS 









CLI 
Module 





mcc_call_function (_ verb = SHOW, 


in_entity = (NODE4 updike CIRCUIT *), 
partition = COUNTERS, 
Information 

Manager 
Dispatcher 


time_spec = (AT now, FOR now)) 
CONTROL 
FM 


mcc_call_access (verb = SHOW, 


in_entity = (NODE4 updike CIRCUIT *), 
partition= COUNTERS, 
Information 
Manager 
Dispatcher 


time_spec = (AT now, FOR now)) 
DECnet 
AM 


NICE PDU ("Read Information Message") 






MATCH (v=show, e=..., a=counters) 















MATCH (v=show, e=node4 ..., a=counters) 












Response Processing: DECnet AM will send up the first 


response with a context handle. The FCL PM makes 
repeated calls until handle shows no more data available. 





11-17, DECmcc Call Example 


Part of the power of DECmcc is the specification of a variety of qualifiers 
that are part of the call interface. These qualifiers provide a great deal of 
control over how a particular call gets interpreted. 

Qualifiers to a call can be specified by any directive. These qualifiers are 
handled at one of four levels (see Fig. 11-18): 
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11-18 Qualifiers in the MCC Call Interface 


¢ presentation module 
e information manager 
° dispatcher 

° target module 


It is up to each management module to process qualifiers. If a qualifier 
is not recognized, an error returns. If the qualifier is recognized, the mod- 
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ule can process it, return an “unsupported” error, or pass it down the line 
for another module to process. 
An example of a qualifier is the “with” clause: 


BRIDGE * WITH STATUS=’ON’ 


“With” is an example of entity filtering, allowing only entities with attrib- 
utes having certain values to be used. The with entity filter is similar to the 
CMIP event filtering discussed earlier. 

The via path qualifier shows the hops along a path through a hierarchy 
of management modules. It shows the network port a module should use 
(i.e., a test of an Ethernet port). The for qualifier is the scope of interest, 
used to show the time that is needed for a call. There are two variants: 


FOR START time 
FOR EVERY time UNTIL time 


Time specifiers show up in a variety of places in DECmcc, such as the 
user interface for display, the mcc_call specification, and internally in the 
management information repository for time stamping data. DECmcc de 
fines two types of time: binary absolute time (BAT) and binary relative time 
(BRT). The power of the time qualifiers can be seen in this example: 


AT EVERY 1:00 (every hour) 
UNTIL 17:00 (until 5 PM) 
START 13:15 
FOR (-0:00) 


The qualifier says “give me an instance sample of data starting at 13:15 
once an hour until 17:00.” 
Another variant is: 


AT EVERY 1:00 (every hour) 
UNTIL 17:00 (until 5 PM) 
START 13:45 
FOR START (-0:30) 
DURATION :30 


This qualifier instructs DECmcc to evaluate the preceding half hour’s worth 
of data starting at 13:45 until 16:45. Note the difference: Scheduling is 
when to do it, scope of interest is what to bring back. 

The at qualifier in the following example says when to start the request, 
the for following it says how often, once begun, to evaluate the request: 


AT START (-0:00) (now) 
FOR EVERY 1:00 

UNTIL 17:00 

START 8:00 DURATION :30 
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at every 1- (every day) 
start (8:00, 17:00) 
for start (-0:00) 


Notice the ability to have a request started every day. The information 
manager will ensure that the relevant calls are issued to the access modules 
to have the call properly performed on a daily basis. 


Management Data 


DECmcc keeps four types of data in the management information reposi- 
tory: 

entity class data 

entity instance data 


entity attribute data 
miscellaneous 


Miscellaneous data are anything a function module chooses to keep in the 
underlying database. One of the prime examples of miscellaneous data are 
historical data kept by the Historical Data Recorder (HDR) function module. 

Figure 11-19 shows the basic flow of dictionary information in the DEC- 
mcc environment. The presentation modules will use entity class informa- 
tion to derive default output formats. The function modules might use 
entity information to provide services based on known classes at this time. 
Class information is added when management modules are first enrolled 
and is not deleted since it is time independent. 

Entity instance data include which entities exist and at what times they 
exist. This information may or not match reality it is the local DECmcc’s 
version of the network. This allows the network manager to look at the 
configuration if the network is down. 

Since entity instance data are time stamped, it allows the manager to 
look at present, past, and future configurations. It is the responsibility of 
the function modules to maintain this instance information. Entity attrib- 
ute data are time stamped, historical data. They are collected by one or 
more function modules but are available to other management modules. 

Miscellaneous information is whatever a module wants to keep. One ex- 
ample is a template of a mail message for use by a function module; an- 
other example is a parse table for a presentation module used to decode 
incoming commands from a human user into the appropriate DECmcc 
calls. 

The dictionary is heavily used by the presentation modules to determine 


° validation criteria for input 
° translation of input strings into internal ID codes 
° determination of presentation names used for input and displays 
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11-19 Flow of Dictionary Information in DECmcc 


¢ determination of the number, data type, prompt string, and default val- 
ues for arguments passed across the interface 

¢ translation from internal ID codes into presentation formats 

° interpretation of status information 


Function modules also use the dictionary to 


¢ determine what entity and subentity classes are defined 

¢ determine if an entity class has the attributes on which a function mod- 
ule operates 

¢ help formulate access module calls and to decode replies 

¢ validate incoming requests 
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Access modules do not really need to use the dictionary, as they already 
know the structure of the entities they can handle. Remember, the purpose 
of the access module is to take the incoming calls and translate them into 
network-specific access calls. 

Entity instance data are maintained and accessed by the configuration 
function module. Entity attribute data are through the HDR Function Mod- 
ule. This module provides an entity attribute polling and storage service. 

Miscellaneous information is created through three types of DECmcc 
calls: 


* mcc_rms creates an RMS file 

* mcc_qiow begins direct device access 

* mcc_mir_create creates a miscellaneous data store managed by the MIR 
manager (i.e., Ingres or Rdb) 


These three examples are for the VMS version of DECmcc. On the Ultrix 
version, the equivalent native operating systems services can be accessed. 


DECmcc Service Routines 


DECmcc routines fall into multiple categories, providing different types of 
support services to the management modules (see Fig. 11-20). Some of 
these routines are tools that are optionally used by the programmer. An 
example is the abstract entity specification routines that let the programmer 
refer to an entity by a “handle.” When repeated calls are being made, the 
entity specification is put into the handle, freeing the programmer from the 
worry of parsing complex entity specifications. 

Other routines, called monitors, provide coordination among different 
modules. Monitors are two kinds: Mutually exclusive monitors provide ac- 
cess to common resource classes, and thread synchronous monitors provide 
access to underlying asynchronous services, that is, a way of blocking other 
threads but not the whole process. Monitors exist for locks, I/O, RMS, 
thread control, and timers. 

For locking, there are four levels of namespaces: 


® per process 
¢ per UIC group 
° per system 
¢ per cluster 


Thread calls let you create and delete a thread. You can also send an 
alert and test an alert and join threads (synchronize with the completion of 
one or all of a set of threads). 
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) -~DECmcc Routines 


Abstract Entity Specification (AES) routines allow the programmer to refer to an 
entity specification by name. They are useful in looking at several different 

attributes by “walking the tree.” 
Abstract Handle Specification (AHS) routines allow the programmer to 
| manipulate the context handle. A context handle can be in three different states 
(first, more, cancel). 
ASN.1 Encode/Decode routines allow the programmer to encode and decode 
based on type length value. It is a way of creating a constructed sequence or set 
of information. 




























Abstract Time Specifications allow the programmer to create a “time frame” 
which has several elements then copy, delete, extract elements, and get the first, 
last, or next element in a time frame. 


Information Manager Routines: MCC_CALL_ACCESS and 
MCC_CALL_FUNCTION. The dispatcher selects the most specific service from the | 
dispatch services. 


DECnet Access routines allow the programmer to set up connections, manage | 

names, read and send messages. | 

Dictionary routines allow the programmer to query the dictionary. For example, | 
find the DECmcc code assigned to the attribute ROOT ID for a DEBET bridge. 
Or, given an MCC code, finds the English name. For each class of global entity, 


the routines provide access to attributes, attribute partitions, directive, and 
subordinate entities. 












| 


















Ethernet Access Routines allow the programmer to get and send packets, show | 
available device IDs, request XID to an entity, and perform an 802 loopback. | 


| Enrollment Routines add a management module to the DECmcc runtime 
environment. 










| ID Code/Length Value (ILV) routines allow the programmer to build lists, append 
| lists to each other, and perform other list manipulations. 


| Framework routines create and manipulate threads and monitors. | 
| I/O routines access RMS and QIOW calls (but without the blocking). | 


1 Timer routines wait. 





MIR routines allow the programmer to create and manage a new private | 
repository, and then read, write, and delete entity data. | 


| Time Conversion Routines are for date arithmetic and to read the current time. 





11-20 DECmecc Routines 


Module Execution Environment 


A management module is a shared image in VMS and a process in Ultrix. 
This means the code should be reentrant (i.e., counters should not be de- 
clared as global variables) and position independent (it will work no matter 
where it is installed in the virtual address space). 
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Within the execution environment, threads are used to allow multiple 
execution paths within a single process. Monitors (semaphores) are then 
used to synchronize access to resources shared by concurrent threads. 


Enrollment and Extensibility 


To enroll a management module, four types of information are needed: 


° The dispatch table entries: the <V,E,A> types and associated entry points 
this module is prepared to handle. 

¢ A Management Specification (MS) written using the Management Speci- 
fication Language (MSL) used to describe the management and service 
interfaces. 

¢ User presentation information derived from the management specifica- 
tion information. It includes the command line interpreter (CLI) parse 
table, the command line input output information, window forms, and 
menu bars. 

° Help information to merge into the DECmcc help libraries. 


When a management module enrolls, it must provide three routines in 
addition to the normal functional routines. An initialization routine is 
called when the management module enrolls. This routine integrates the 
dispatch tables into the DECmcc dispatch table and maps the management 
module’s shareable image. The PROBE routine is called the first time a 
user wants the services of this module. It maps the management module 
into the user address space. The LOG routine is called right after the probe 
and is used for logging information during debugging. 

There are basically six steps to enroll a module (see Fig. 11-21): 


e Execute the MSL translator. 

¢ Execute the help file builder. 

¢ Execute the parse table builder. 

¢ Execute the forms builder. 

°¢ Merge dispatch tables. 

¢ Map the management module (MM) shareable image into memory. 


The translator does two things: First, it merges the management specifica- 
tion information into the dictionary for future use by programs such as the 
parse table builder. Second, it creates a constant declaration file. 

Registration is the process of getting a unique code for information. 
Typically, you would go to Digital, which would assign/validate codes. If a 
management module is being sold, registry with Digital assures there is no 
conflict. If the MM is a unique, private module, registration is advised in 
that it prevents conflicts with future commercial management modules. In- 
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formation from the management specification that gets registered includes 
the following: 


* primitive data types 

constructed data types 

entity information: class name and code 
attribute partitions 

directives 

responses to directives 

exceptions to directives 

common exceptions 

° arguments 

¢ qualifiers 


Figure 11-22 shows a portion of a management specification, taken from 
the DECmcc manual. The example specification defines an entity with the 
symbol “NETDEV.” Then, the primary identifier, the Phase IV name, Phase 
IV address, and other identifiers are defined. Next, several attributes of the 
network are described. First is the send rate, a settable attribute with a 
default value of 1000 bytes per second. 

After the characteristic, settable attributes come the status counters such 
as the total number of user bytes sent. Following that, an attribute group is 
defined. Notice that this management specification closely follows the net- 
work management architecture of entities, identifiers, attributes, and 
groups defined in the beginning of this chapter. Directives, exception re- 
ports, and other aspects are also defined in the MS language. 


The Help System 


The automatic help system allows the network manager to, find out more 
about entities, attributes, and other things in a management module. This 
dynamic help system is important because new management modules may 
be enrolled at any time. Help information is in one of four categories: 


¢ entity information (provided by the access module) 
¢ function information 

* presentation information 

* tutorials 


Within each category, there are several levels of help information. The ba- 
sic hierarchy is 


° entity 
° entity classes 
¢ subordinate entity classes 





MANAGEMENT SPECIFICATION . 
EXAMPLE_AM; 
VERSION = 11.0; 
SYMBOL_PREFIX = EXAMPLE_ ; 
GLOBAL ENTITY NETDEV = 100 ; 
IDENTIFIERS = (Name, Address), 
DYNAMIC = FALSE; 
SYMBOL = NETDEV, 
IDENTIFIER ATTRIBUTES 
ATTRIBUTE Name = 01 ; Phase4Name 
(* This is the primary identifier *) 
ACCESS = NONSETTABLE, 
DISPLAY = TRUE, 
DEFAULT = NO DEFAULT, 
SYMBOL = NEDEV_NAME, 
CATEGORIES = (CONFIGURATION) 
END ATTRIBUTE Name; 
ATTRIBUTE Address = 02 : Phase4Address 
ACCESS = NONSETTABLE, 
DISPLAY = TRUE, 
DEFAULT = NO DEFAULT, 
SYMBOL = NEDEV_ADDRESS, 
CATEGORIES = (CONFIGURATION) 
END ATTRIBUTE Address; 
END ATTRIBUTES; (* Identifier *) 
CHARACTERISTIC ATTRIBUTES 
ATTRIBUTE Send Rate = 713 : Unsigned32 
ACCESS = SETTABLE, 
DISPLAY = TRUE, 
UNITS = “Bytes Per Second”, 
DEFAULT = 1000, 
SYMBOL = NEDEV_SEND_RATE, 
CATEGORIES = (CONFIGURATION) 
END ATTRIBUTE Send Rate; 
ATTRIBUTE Receive Rate = 756 : Unsigned32 
ACCESS = SETTABLE, 
DISPLAY = TRUE, 
UNITS = “Bytes Per Second”, 
DEFAULT = 1000, 
SYMBOL = NEDEV_RCV_RATE, 
CATEGORIES = (CONFIGURATION) 
END ATTRIBUTE Receive Rate; 
END ATTRIBUTES; (* CHARACTERISTIC *) 
COUNTER ATTRIBUTES 
ATIRIBUTE User Bytes Sent = 10 : Counter32 
ACCESS = NONSETTABLE, 
DISPLAY = TRUE, 
UNITS = *‘Bytes”’, 
DEFAULT = NO DEFAULT, 
SYMBOL = NEDEV_USER_BYTES_SENT, 
CATEGORIES = (CONFIGURATION) 
END ATTRIBUTE User Bytes Sent ; 
ATTRIBUTE User Bytes Received = 11: 
Counter32 











DISPLAY = TRUE, 
UNITS = “Bytes”, 
DEFAULT = NO DEFAULT, 
SYMBOL = NEDEV_USER_BYTES_RCVD, 
CATEGORIES = (CONFIGURATION) 
END ATTRIBUTE User Bytes Received ; 
END ATTRIBUTES; (* COUNTER *) 


ATTRIBUTE GROUP Send and Receive 
Inf = 20 ; 
ATTRIBUTE-LIST = (Send Rate, 
Receive Rate, 
User Bytes Sent, 
User Bytes Received), 
DIRECTIVES-SUPPORTED = (Show), 
CATEGORIES = (CONFIGURATION) 
END ATTRIBUTE GROUP 
Send and Receive Inf ; 
DIRECTIVE Show = 01 ; 
DIRECTIVE-TYPE = EXAMINE, 
DISPLAY = TRUE, 
SYMBOL = NETDEV_SHOW, 
CATEGORIES = (CONFIGURATION), | 
(* Note: No REQUEST arguments required *) | 
RESPONSE Examine Complete = 1; 
SYMBOL = EXAMINE_COMPLETE, 
ARGUMENT Examine List = 1 : Aftrib_List 
DISPLAY = TRUE, 
SYMBOL = EXAMINE_LIST 
END ARGUMENT Examine List; 
END RESPONSE Examine Complete; 
EXCEPTION Unrecognized Argument = 0 : 
SYMBOL = UNREC_EXAM_ARG, 
ARGUMENT 
Exception Class = 0 : ExceptionClass 
DISPLAY = FALSE, 
SYMBOL = EXCEPTION_CLASS 
END ARGUMENT Exception Class; 
END EXCEPTION Unrecognized Argument; 
END DIRECTIVE Show; 


DIRECTIVE Set = 2: 
DIRECTIVE-TYPE = MODIFY, 
DISPLAY = TRUE, 
SYMBOL = SET_DIRECTIVE, 
CATEGORIES = (CONFIGURATION), 
REQUEST 
ARGUMENT Modify List = 1 : Attrib_List 
SYMBOL = SET_MODIFY_LIST 
END ARGUMENT Modify List; 
END REQUEST ; 
RESPONSE Modify Complete = 1; 
SYMBOL = MOD_COMPLETE, 
END RESPONSE Modify Complete; 
EXCEPTION Unrecognized Argument = 0: 
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! SOURCE: DECmec Manual, pp. 186-187 
| File: MCCSNETDEV_AM.HELP 
WINDOW_TOPICS . 

ENTITY NETDEV = NETDEV 

ENTITY NETDEV CHARACTERISTICS SEND_RATE = NETDEV_CHAR_SR 
ENTITY NETDEV CHARACTERISTICS RECEIVE_RATE = NET- 
DEV_CHAR_SR 

| 

ENTITY NETDEV COUNTERS = NETDEV_CNT 

ENTITY NETDEV COUNTERS USER_BYTES_RECEIVED = NET- 
DEV_CNT_UBR 

ENTITY NETDEV COUNTERS USER_BYTES_SENT = NETDEV_CNT_SNT 

| 












ENTITY NETDEV IDENTIFIERS = NETDEV_IDENT 
ENTITY NETDEV IDENTIFIERS NAME = NETDEV_IDENT_NAME 
ENTITY NETDEV IDENTIFIERS ADDRSS = NETDEV_IDENT_ADDRESS 
| « 

ENTITY NETDEV SEND_AND_RECEIVE_INFO = NETDEV_SARI 
| 










ENTITY NETDEV SET = NETDEV_D_SET 
ENTITY NETDEV SHOW = NETDEV_D_SHOW 





| 

KEY = NETDEV 
Network Device help text. 

KEY = NETDEV_CHAR : 
Network Device Characteristics help text. 
KEY = NETDEV_CHAR_SR 
KEY = NETDEV_CHAR_RR 


MCC> HELP 
Additional information available: 


ENTITY FUNCTION PRESENTATION TUTORIAL 












Topic? ENTITY 






ENTITY 






Entity help text. 







Additional information available: 


NETDEV 






ENTITY Subtopic? NETDEV 







ENTITY 
NETDEV 






Network Device help text. 







Additional information available: 






CHARACTERISTICS COUNTERS INDENTIFIERS 
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For each subordinate entity class, there is information on directives, attrib- 
ute partition, and attribute groups, Under directives there is information 
on requests, responses, and exceptions, with information for arguments on 
each. 

The presentation tree is similar, including: 


° presentation category 
¢ PM module 

¢ UI Feature 

¢ UI Subfeature 


Each management module produces a help file under the name 
mcc_name.help written in the help specification language. Figure 11-25 
shows an example from the DECmcc manual of the help specification lan- 
guage. Figure 11-24 shows a sample help session using the topics specified 
in Figure 11-23. 


Modules 


DECmcc provides the platform to develop different modules. Several mod- 
ules have been developed allowing management of a heterogeneous envi- 
ronment from a single platform. Access modules, for example, have been 
written to manage Phase IV, Phase V, LAN bridges, TCP/IP SNMP, and 
FDDI. 

Of particular interest are the different function modules and presenta- 
tion modules available. Figures 11-25 through 11-28 show the window- 
based screens that illustrate a variety of the functions provided in early 
releases of DECmcc. 

Figure 11-25 shows a map of the network topology. Notice the small win- 
dow has a picture of the domain being managed, the United States. The 
manager has zoomed in on the Northeast, showing the links coming out of 
Littleton, Massachusetts. The toolbox has a variety of icons allowing the 
manager to pick different tools. The domain management tool, already se- 
lected, allows the manager to separate a large complex network into differ- 
ent domains. 

Figure 11-26 shows a more detailed view of the Massachusetts facility, 
including a topology map of the network. Notice that miscellaneous MIR 
information has been used to give names to all the nodes. The network 
shows that a variety of Ethernet systems is connected together using bridge 
systems. Notice there are two more domains that could be examined even 
further—IP-DOMAIN and LKG-C. 

Figure 11-27 shows the automatic forms creation capability of DECmcc. 
The operation SHOW COUNTERS, for example, generates a query that will 
examine the operation of a bridge. The user clicks on the bridge and the 
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window will open. The different counters available for this bridge are dis- 
played in the window. Next to the show counters window is the show char- 
acteristics window. Again, a form is automatically created to show the 
relevant characteristics. In both windows, the display will be continually 
updated to show the current version of the data. 

What has happened here is that the window-based presentation manager 
has used the dictionary to find out what the form should look like. When 
the user hits the start operation button on the form, the presentation mod- 
ule issues a mcec_call_ function call, specifying the entity BRIDGE MY- 
BRIDGE. This is intercepted and eventually turned into an access module 
call down to the bridge management module. 

Figure 11-28 shows an especially powerful function module, the alarms 
module. The user is able to define the conditions for an alarm. In this 
case, a rule was defined that said that when a bridge was working success- 
fully, it should trigger an alarm. The alarm did two things. First, it 
changed the color of the network map. Second, it sent an automatically 
generated electronic mail message to the network manager. The alarm 
module could just as easily have used DECtalk, a voice generation system, 
and a modem to call the network manager at home and give him or her 
this information. 


Summary 


Digital’s network management architecture has many pieces. The CMIP 
protocols in OSI are a means of moving management directives and reports 
around the network. The node architecture defines how modules on a 
DECnet node will provide management information. 

Since network management is more than just DECnet or OSI, Digital pro- 
vides an architecture for the management director, EMA. EMA, and the 
resulting implementation of DECmcc, provide management capabilities for 
multiple network architectures. In fact, DECmcc can be used for system or 
application management, tasks not usually combined with network man- 
agement. 

The access modules of DECmcc allow remote entities to be managed. 
The real power, however, is in the functional management capabilities. Al- 
lowing historical data records, alarm modules, and WAN topology mapping 
to work together gives the network manager a wide variety of tools to use. 
How to use those tools effectively could easily be the subject of another 
book, so we terminate this book on that thought. 
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1003.1 
1003.4 
1003.6 
1003.7 
1003.8 


10BASE2 


10BASE5 


10BASET 


2780/3780 


ot 


3090 


3270 


3270 Display 
Stations 


Glossary 


POSIX general definition. 

POSIX real-time extensions. 

POSIX security extensions. 

POSIX system management extensions. 
POSIX networking extensions. 


10 Mbps/baseband/200 meters. IEEE standard for thinwire 
Ethernet. 


10 Mbps/baseband/500 meters. IEEE standard for thickwire 
coaxial Ethernet. 


10 Mbps/baseband/twisted pair. IEEE standard for twisted 
pair Ethernet. 


A model of remote batch terminals used in IBM bisynchro- 
nous environments. Bisync gateways are often referred to 
as 2780/3780 emulators. 


5Com networking products. 
IBM top of the line mainframe, sometimes called Sierra. 
A series of terminals used in IBM environments. 


Terminals for IBM mainframe computers. 


1003.1 tim» 3270 Display Stations 
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3274 


3480 


370 architecture 


3705 


3725 


3Com 


4.3BSD 


4010/4014 


423 


4GL 


5250 


802.2 


802.3 


802.4 


802.5 


80286 


80x86 


3274 \1mp 80x86 


A cluster controller for IBM equipment, often called a termi- 
nal concentrator. 


IBM tape cartridges. 


IBM architecture for mainframe computers, including the 
5090 processors. 


An IBM communications controller. A PU Type 4 in SNA 
used to connect token ring networks, cluster controllers, 
non-IBM SNA gateways, and other devices to a PU Type 5 
host. 


See 3705. 


A communications company known for Ethernet controllers 
and PC-based networking equipment. Merged with Bridge 
Communications. 


4.3 Berkeley Software Distribution. The current version of 
the Berkeley family of Unix products. 


A series of Tektronix graphics terminals. A de facto stand- 
ard for graphics terminals. 


See EIA-423. Abbreviation used in DECconnect. 
See fourth-generation language. 

IBM terminal used on the System/3X line. 

IEEE standard for the Logical Link Control. 


IEEE standard for CSMA/CD (Ethernet) medium access 
method. 


IEEE standard for the token bus medium access method. 
IEEE standard for the token ring medium access method. 


An Intel chip used in the IBM PC/AT and clones. The 80386 
is used in new high-end PS/2s and Compaq computers. 


Family of microprocessors made by Intel used in the PC 
line. The PC/AT uses the 80286 chip. More modern sys- 
tems, including the PS/2, use the 32-bit 80386 chip. 
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9370 


A 


A Tools 
Integration 
Standard 


ABM 


abstract data type 


AC 


access control set 


access method 


access module 


ACF 


ACK 


ACL 


Midrange IBM processor. 


AT&T Modular Jack. Abbreviation used in DECconnect. 


Digital extensions to CDD/Plus to support object-oriented ex- 
tensions to the data dictionary. 


See Asynchronous Balanced Mode. 


Concept used in programming and database systems. An 
abstract data type is a user-defined data type that hides the 
internal details of its manipulation. For example, date, an 
abstract data type, is stored internally as an integer but is 
manipulated externally through date-specific repre- 
sentations and operations. 


Access control. Token ring field that holds the priority and 
reservation bits for a token or data packet. 


A set of identifiers of objects and their associated rights to 
some entity (i.e., a node or a file). 


A means of accessing information in a file. Btree is an ex- 
ample of an access method. 


An EMA concept. The access module is responsible for the 
primitive interface to management protocols such as CMIP, 
which in turn accesses the managed entities. See also func- 
tion module and presentation module. 


Access Control Facility Security system for the MVS operat- 
ing system. 


Acknowledge. A network packet acknowledging the receipt 
of data. 


Access Control List. A security feature that allows security 
on objects to be specified as a list of permitted actions for 
particular lists of users. Both the VMS operating system 
and the DNA Naming Service have (different) ACL capabili- 
ties. 


9370 1m ACL 
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ACP 
ACS 


ACSE 


ACT 


active converter 


active device 


active monitor 


Active Monitor 
Present 


ADDMD 


addressing 
authority 


address space 


ADMD 


ADT 


Advanced 


Program-to-Program 


Communication 


Ancillary Control Process. See NETACP. 
See Access Control Set. 


Association Control Service Elements. Core set of facilities in 
the OSI application layer that allow application entities to 
form an association. 


Number of active connectors. Abbreviation used in DECcon- 
nect. 


A device used to convert from one communication signaling 
interface to another. Digital has an active converter for con- 
verting from EIA 232-D to EIA 423-A. 


A device with its own power source. 


A computer on a token ring that acts as the controller for 
the ring, regulating the token and other performance as- 
pects. 


Packet issued every 3 seconds by the active monitor on a 
token ring. 


Administration Directory Management Domain. An X.500 di- 
rectory management domain maintained by a public tele 
communications entity that is a member of the CCITT. 


The group responsible for assigning addresses within a do- 
main. 


A collection of addresses that form a unified collection such 
as an internetwork. 


Administration Management Domain. X.400 message-han- 
dling system concept. Countries will typically be an ADMD. 
They might then delegate management authority to a pri- 
vate management domain (PRMD). 


See Abstract data type. 


Protocol used for peer-to-peer communication in IBM’s Sys- 
tem Network Architecture. 


ACP imp Advanced Program-to-Program Communication 
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advertising 


AFP 


aged packet 
agent 


aggregate 


AK TPDU 
alias 


ALL-IN-1 


allocation 


AM 


American National 
Standards Institute 


American Wire 
Gauge 


The process by which a service makes its presence known 
on the network. Typically provided through some form of 
LAN-based multicast. 


Application Environment Specification. OSF look and feel 
standards based on the X Windows System. 


Authority and Format Identifier. Part of an OSI address that 
signals what type of address follows the AFI. 


See AppleTalk Filing Protocol. 


A routing layer packet that has exceeded the maximum 
number of visits. 


Network management term for the portion of an entity that 
responds to management functions. 


A function in a query language used to perform an opera- 
tion on several rows of data. Sum is an example of an ag- 


gregate. 


Abstract Handle Specification Set of DECmcc routines used 
to establish and manipulate context handles. 


Acknowledge Transport Protocol Data Unit. A protocol data 
unit type in the OSI transport service. 


A name that is translated into another name. A DNS soft 
link is an example of an alias. 


Digital’s office automation shell, consisting of a menu 
driver, a mail user interface, a calendar manager, and a file 
manager. 

Concept used in the transport layer protocols. An allocation 
is the amount of unacknowledged traffic that may be out- 
standing at one time. 

See Access Module. 

Private organization that coordinates some United States 
standards making. Represents the United States in the In- 


ternational Organization for Standardization (ISO). 


Standard used to describe the size of a wire. 


advertising 11m American Wire Gauge 
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A-mode 


ANSI 
AMP 


annular mark 


ANSI 


API 


APPC 


AppleTalk 


AppleTalk Filing 
Protocol 


application 


Application 
Control Services 


application layer 


application 
programming 
interface 


application 
terminal 


Asynchronous Mode. Used in the OSI Virtual Terminal pro- 
tocols. A model for terminal operation where either side 
may communicate at any time. 


See American National Standards Institute. 
See Active Monitor Present. 


The mark on an Ethernet coaxial cable that identifies the 
2.5-meter separation required for nodes. 


See American National Standards Institute. 

See application programming interface. 

See Advanced Program-to-Program Communication. 
Apple’s network protocol. 


The protocol in AppleTalk used for remote access to data. 


A program that performs functions for a user. Order entry 
system or word processors are both examples of applica- 
tions. 


The rules used for application to application interaction in 
an NAS environment. 


The top layer of the network protocol stack. The application 
layer is concerned with the semantics of work. For exam- 
ple, getting a certain record from a file by key value on a 
foreign node is an application layer concern. How to repre- 
sent that data and how to reach the foreign node are issues 
for lower layers of the network. 


Specification of the calling structure between two programs, 
usually between a general application program and a spe- 
cific support service, such as communications support. 


A LAT object accessed by an application on a slave node. 
For example, a printer attached to a terminal server would 
be the application terminal for the print spooler. 


A-mMode iia» application terminal 
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architecture 


ARCNET 


areas 


Arpanet 


array 


ASCII 


ASN.1 


A set of plans that allow different components to work to- 
gether. A network architecture allows different computers 
on a network to communicate. An information architecture 
allows different users to access a variety of data repositories. 


Hardware and software data link components manufactured 
by Datapoint and other companies that allow computers to 
form a 2.5-Mbps local area network with a star topology. 


A DECnet term used in the routing layer. Level 1 routers 
are used to route within a DECnet area, level 2 routers route 
between areas. In Phase IV, up to 1023 nodes may be in an 
area; up to 63 areas may be in a DECnet routing domain. 
DECnet Phase IV was limited to 63 areas, whereas Phase V 
has essentially no limits. 


Address resolution protocol. A TCP/IP protocol to translate 
an IP address into a physical address (i.e., an Ethernet or 
other subnetwork address). 


A Department of Defense sponsored network of military 
and research organizations. Being replaced by the Defense 
Data Network. 


A data structure used in programming. 


American Standard Code for Information Interchange. A 
standard character set that assigns an octal sequence to each 
letter, number, and selected control characters. The other 
major encoding standard is EBCDIC. 


Abstract syntax notation. The language used in the OSI 
presentation layer to define complex objects. 


Abstract Syntax Notation One. OSI presentation layer proto- 
col. 


Asynchronous system trap. A concept used in the VMS lock 
manager. An AST is a request to be notified when a certain 
event occurs. In the case of the lock manager, an AST can 
be set so a process holding a lock on a resource is notified if 
another process tries to take an incompatible lock on the 
same resource. 


architecture tm AST 
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async 


asynchronous 
balanced mode 


asynchronous 
communication 


asynchronous 
event 


asynchronous 
mode 


ATIS 


attenuation 


attenuation 
characteristic 


attribute 


attribute group 
audit trail 
authentication 


authorization 


async iim authorization 


Asynchronous. A data transmission method that sends one 
character at a time. It is contrasted with synchronous meth- 
ods that send a packet of data and then resynchronize their 
clocks. Asynchronous also refers to commands, such as in a 
windowing environment, that may be sent without waiting 
for a response from the previous command. 


A term used in the IEEE 802.2 standard to refer to a situ- 
ation where only one side of the connection can send. 


Communication in which every byte is sent individually. 
Synchronous communication (i.e., X.25 or Ethernet) 
bunches several pieces of data into a frame or packet. 


Events occur asynchronously on a system when you cannot 
predict which one will happen next. 


FDDI term for data transmission where all requests for serv- 
ice contend for a pool of ring bandwidth. 


See A Tools Integration Standard. 


The level of signal loss, usually expressed in units of deci- 
bels. 


As a signal propagates on a cable, it gets weaker, or attenu- 
ates. The attenuation characteristic of the medium is the 
rate at which it gets weaker. 


A “perceived property” of some entity that can be read, and 
maybe modified. Attributes are used in network manage- 
ment as well as in the naming service. An example is the 
password attribute of the object user. In a relational data- 
base, attribute is another name for a column in a table. Ina 
data dictionary or other information model, an attribute is 
attached to a relationship or entity. 


A named collection of attributes. 
A record of all actions performed on some entity. 
The function of verifying the identity of a person or process. 


Determining if a person or process is able to perform a par- 
ticular action. Contrast with authentication. 
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AUTHORIZE 


autobaud 


AWG 


backbone 


balun 


bandwidth 


baseband 


BASIC 


BAT 


baud 


Bayonet nut 
connector 


BEA 


beacon 


BI bus 


A VMS utility used to add new users and define relevant 
parameters such as privileges and default login directories. 


The ability of a modem on the receiving end of a call to 
detect automatically the speed of transmission used by the 
calling modem. 


See American Wire Gauge. 


A networking term used to refer to a piece of cable used to 
connect different floors or departments together. Con- 
trasted with a departmental network or work area network. 


balanced/unbalanced. An adapter between two different 
pieces of physical media that adjusts for the difference in 
impedance. 


The amount of data that can be moved through a particular 
communications link. Ethernet has a bandwidth of 10 
Mbps. 


Coax cable implementation of Ethernet. Also Known as 
ThickWire. 


Beginner’s All-purpose Symbolic Instruction Code. A program- 
ming language. 


See Binary absolute time. 


A term used with older (slow) modems to refer to each 
modulation of an analog signal. A 300-baud signal modu- 
lates 300 times per second. A more accurate term for faster 
modems is bits per second, since several bits can be carried 
on one modulation of the signal. 


Connector type used for 10BASE2 (thinwire) coaxial cable. 
The term bayonet refers to the way the connector slides in 
and then twists to lock the connection. 


See broadcast end node adjacency. 


A token ring packet that signals a serious failure on the 
ring. 


Backplane interconnect. A peripheral bus used on Digital’s 
8000 series VAXs. The BI bus operates at a speed of 13.3 
Mbps. 
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big endian 


BIH 


binary absolute 
time 


binary relative 


time 


binary tree 


BIND 


binding 


BIOS 


bisync 


block 


blocking call 


BNC 


BNF 


boot nodes 


A computer that stores a multioctet data structure with the 
lowest addressed octet as being the most significant. See 
also endian and little endian. 


International Time Bureau. The organization responsible for 
maintaining coordinated universal time (UTC). 


Time specified as coordinated universal time (UTC), a time 
differential factor (TDF), and an inaccuracy term. See also 
binary relative time. 


A time system specified by its relationship to its current 
time. 


Often referred to as a Btree. A storage structure with a dy- 
namic index used for environments with frequent updates 
to data. 


An SNA term used to establish a session between two logical 
units. 


Concept used in remote procedure calls. Two remote pro- 
grams bind with each other by starting a connection then 
exchanging command requests. 


Basic input/output system. The MS-DOS library of calls for 
access to data. Shields the application from the different 
types of physical disks. 


A synchronous protocol used in older IBM teleprocessing 
environments. See also BSC. 


A unit of I/O on VMS computers. 512 bytes. 


A procedure call where the caller halts its own execution 
until the called procedure finishes. 


See Bayonet Nut Connector. Abbreviation used in DECcon- 
nect. 


Backus-Naur Form. A way of representing a language and 
its elements. 


Used in Local Area Vax Clusters to refer to the node that 
stores the operating system for other nodes in the cluster. 


big endian |im boot nodes 
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BOS 


bps 


BRA 


bridge 


broadband 


broadcast 


broadcast end 
node adjacency 


broadcast router 
adjacency 


brouter 


BRT 
BSC 
BSD 
Btree 
bucket 


buffer 


Binary object sequence. The lowest level of access to a Post- 
script Interpreter. Higher levels are Postscript program- 
ming library calls and ASCII interfaces. 


Bits per second. Transmission speed on modems, phone 
lines, and other data communications devices. 


See broadcast router adjacency. 


A device used to connect two separate Ethernet networks 
into one extended Ethernet. Bridges only forward packets 
between networks destined for the other network. Term 
used by Novell to denote a computer that accepts packets at 
the network layer and forwards them to another network. 


An analog medium similar to cable TV. Large bandwidth 
and very long distances make this medium appropriate for 
campus settings. Used with various data link protocols in- 
cluding Ethernet and token buses. 


Sending information to all users of a particular service. An 
Ethernet broadcast, for example, sends an Ethernet packet 
to every address on the network. 


A DNA routing layer concept for an end node reachable 
over the same subnetwork to which the routing module is 
connected. 


A router connected to the same broadcast circuit as this 
node. 


Bridge/router. Device that forwards messages between net- 
works at both network and data link levels. 


See Binary relative time. 

Bisynchronous. See bisync. 

Berkeley Standard Distribution. See 4.3BSD. 

See binary tree. 

A group of a file’s virtual blocks used for I/O transfer. 


A portion of main memory on a computer used to hold 
data. 


BOS 1m buffer 
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bursty traffic 


bus 


CA 


cable patch panel 


cached 


called stub 


capture 

Carrier 
Sense—Multiple 
Access/Collision 
Cartesian product 
CATV 


CC 


CCA 


CCITT 


bursty traffic im CCITT 


Data communications term referring to an uneven pattern 
of data transmission. 


The part of a computer that connects peripheral devices so 
that they may communicate with the CPU and memory. 
IBM’s Micro Channel Architecture is an example of a pe 
ripheral bus architecture. 


See certification authority. 


A device located in the satellite equipment room. Used to 
connect two sets of wire (i.e., the wire from the satellite to 
the office and the wire between the satellites). 


A piece of information retained in main memory instead of 
being flushed to disk. Keeping information cached allevi- 
ates the need to go to the disk to retrieve the data. 


A piece of code used in an RPC mechanism. The called stub 
masks the remote nature of the call from the procedure on 
the RPC server. 


The act of removing a token from the ring. 


The methodology used in Ethernet to mediate access to a 
single physical medium among multiple computers. 


Given two lists of data, the Cartesian product is the set of 
every possible combination of the two lists. 


Community Antenna TV. The type of cable used in broad- 
band networks. 


Connect Confirm. A protocol data unit type in the OSI 
transport service. 


Conceptual Communication Area. Part of the ISO Virtual 
Terminal service. The CCA is an abstract area that provides 
a common view of the virtual terminal between two appli- 
cations. 


Comité Consultatif International Télégraphique et Téléphonique. 
Standards-making body administered by the International 
Telecommunications Union. 
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CCR 


CCS 


CDA 


CDD 


CD-ROM 


CDT 


certification 
authority 


channel 


characteristic 
attribute 


CheaperNet 


CI bus 


CICS 


Commitment, concurrency, and recovery. Part of the OSI ap- 
plication service elements that allows the coordination of 
multiple users access to data on multiple nodes. 


Common communications support. A portion of IBM’s Sys- 
tem Application Architecture (SAA). 


See Compound Document Architecture. 


Common Data Dictionary. Digital’s software that functions 
as a common repository for data definitions, forms, data- 
base schemas, and other parts of an information system. 
Part of the VAX Information Architecture. 


Compact Disk—read only memory. Optical disks that are 
mastered then can only be read. Used for read only data- 
bases. 


Credit. A field used for flow control in the OSI transport 
service. 


A software process used in X.509 or RSA (public key) authen- 
tication schemes. The certification authority maintains the 
public keys for users. In some architectures the certification 
entity is off line and public keys would be stored in a name 
service. 


An IBM term referring to a direct high-speed connection 
into the 370 architecture machine. A “channel attach” de- 
vice operates at speeds up to 3 Mbps, as opposed to more 
traditional devices that attach to a communications control- 
ler at 56 kbps. 


A system management concept for an attribute that can be 
changed or modified by a director, thus affecting the behav- 
ior of that entity. 


Another term for ThinWire Ethernet cables. 


Computer-room interconnect. Refers to the 70-Mbps bus and 
controllers used in the VAX Cluster arrangement. To be 
contrasted with Local Area VAX Clusters that use a 10-Mbps 
Ethernet as the transport mechanism. 


Customer information control system. An IBM data commu- 
nications interface used with the MVS operating system. 
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circuit 


CIT 


class driver 


clearinghouse 


CLI 


client 


CLNS 


Closed User Group 


cluster 


Cluster 
CMA 


CMIP 


Circuit im. CMIP 


A term used in networking that refers to a logical stream of 
data between two users of the network. A single physical 
link may have several virtual circuits running on it. 


Computer Integrated Telephony. Digital architecture and 
products for integrating PBXs into a computer network. 


A term used in VMS. A device driver is used to present data 
to a particular piece of hardware, for example, a terminal. 
In VMS, there are two levels of device drivers. The class 
driver is generic such as a terminal class driver. Under- 
neath the class driver is a physical driver that accepts com- 
mands for a specific type of terminal such as a directly con- 
nected terminal or a remote terminal session using the LAT 
protocols. The class driver shields the user of the device 
from knowing about the particular physical connection 
used. 


A collection of names such as used in DNS. A user would 
query the clearinghouse (also known as a name server) to 
find the location of a particular resource at that time. 


Command line interpreter. Older style of user interface, to 
be contrasted with graphical or forms interfaces. 


A module that uses the services of another module. The ses- 
sion layer is a client of the transport layer, for example. 


Connectionless network service. One of two options for the 
OSI network layer. See also CONS. 


Data communications concept for CCITT (X.25 and ISDN) 
where only certain users (network addresses) can access a 
local connection. 


A file system concept. A disk is made up of a series of clus- 
ters. The clusters are dynamically allocated to files and di- 
rectories as needed. Similar to a block. 


See VAX Cluster. 
See Concert Multithread Architecture. 


Common Management Information Protocol. OSI network 
management protocols used in DECnet Phase V. 
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CMOT 


CMS 


COBOL 


CODASYL 


Communication 
and Control 
Services 


Compound 
Document 


Compound 
Document 
Architecture 


concentrator 


Concert 
Multithread 
Architecture 


concurrency 


conferencing 


CMIP over TCP/IP. An implementation of the OSI CMIP 
protocols over TCP/IP instead of OSI. Allows current net- 
works to take advantage of the enhanced capabilities of 
CMIP without running the entire OSI protocol stack. 


Code Management System or Conversational Monitor System. 
Code Management System is a Digital software product 
used in the VMS environment as a library for program de- 
velopment. Conversational Monitor System is the user in- 
terface on IBM’s VM/CMS operating system. 


coaxial. A type of cable used for IBM 3270 terminals as 
well as for baseband and ThinWire Ethernets. 


Common business-oriented language. One of the first stand- 
ardized computing languages. See CODASYL. 


Conference on Data Systems Languages. The committee that 
developed COBOL as well as the CODASYL standard for da- 
tabases using the network model of data management. 


NAS concept for the API that allows an application to access 
communication services on the network. 


A document with multiple types of information, such as 
text, graphics, and voice. 


Digital architecture for the creation, storage, and manipula- 
tion of compound documents. 


A node on an FDDI ring that provides connections to addi- 
tional stations. Known as a multistation access unit or MAU 
in 802 token rings. 


Digital technology for a portable multithreaded architecture. 


Multiple users attempting to access the same resource. A 
lock manager addresses the problem of maintaining the in- 
tegrity of resources in a concurrent environment. 


A term used for communication software that allows partici- 
pants to “post” notes. Contrasts with electronic mail in that 
participants do not have to be explicitly addressed. Also 
known as a bulletin board. 


CMOT im conferencing 
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confidence 


connection 
manager 


CONS 


COR 


CPP 


CR 


CRC 


credit 


CSMA/CD 


CT 


CTERM 


CUA 


confidence im CUA 


DNA transport layer variable indicating the probability a 
network connection to the destination is currently working. 


A cluster term used to refer to the software component in a 
VAX Cluster or LAVC that maintains the integrity of the 
cluster by managing state transitions. 


Connection oriented network service. One of two options for 
the OSI network layer. See also CLNS. 


Confirmation of Receipt. From OSI Network Service Defini- 
tion. 


See cable patch panel. 


Connection Request or carriage return. A connection request 
is a protocol data unit type in the OSI transport service. 


See cyclic redundancy check. 


A flow control mechanism used in Digital’s LAT protocols. 
A node is allowed to send a packet only if it has a credit 
available. If not, it must wait for the remote node to send 
one. 


See Carrier Sense—Multiple Access/Collision Detect. 


Channel transport. An advanced model of Digital’s DEC- 
net/SNA Gateway. 


Command Terminal Protocol. Part of the virtual terminal 
service in layer 6 of the Digital Network Architecture. An 
alternative to the CTERM services is the Local Area Trans- 
port Architecture (LAT). 


Current transformation matrix. A term used in the Post- 
script Imaging System to denote the transformation be- 
tween user space and device space. 


Creation Time Stamp A Digital Naming Service attribute. 


Common user access. The common user interface compo- 
nent of IBM’s System Application Architecture. Similar con- 
cepts exist with Xerox’s Open Look standard and within the 
DECwindows environment. 
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CUG 


cyclic redundancy ~ 


check 


DA 


daemon 


DAP 


DARPA 


DAS 


DASS 


Data Access 
Protocol 


data 
circuit-terminating 
equipment 


data country code 


Data Distributor 


See Closed User Group. 


A number derived from a set of data that will be transmit- 
ted. By recalculating the CRC at the remote end and com- 
paring it to the value originally transmitted, the receiving 
node can detect some types of transmission errors. 


Condition Values Returned DECmcc term for a status vari- 
able. 


Destination address. 


A Unix term referring to a process that is not connected 
with a user but performs services, such as a mail daemon. 
The equivalent VMS term is a detached process. 


See Data Access Protocol or Directory Access Protocol. 


Defense Advanced Research Projects Agency. A Department of 
Defense agency that has helped fund many computer pro- 
jects including Arpanet, the Berkeley version of Unix and 
TCP/IP. 


See Dual Attachment Station. 


Distributed Authentication Security Service Digital 
system based on public key technology. 


security 


A protocol used in the Digital Network Architecture in layer 
6. Provides a rich set of functions used for exchanging data 
between two nodes of the network. See also File Access Lis- 
tener. 


Term used in X.25 networks for the device on the edge of 
the network that accepts and initiates calls. The DCE is in 
turn connected to a DTE that communicates with the user. 


An ISO-administered format for unique OSI addresses based 
on geographic location. The codes are defined in ISO 3166. 
See also International Code Designator. 


A Digital software product for extracting portions of DSRI- 
compatible databases and replicating this data on another 
node of the network as an Rdb database. 


CUG im Data Distributor 
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datagram 


DATAPAC 


Data terminal 
equipment 


DB2 


DBMS 


DC 


DCA 


DCC 


DCE 


D-CON 


DDCMP 


datagram ii» DDCMP 


A bundle of information exchanged by two units in a net- 
work. Datagram usually refers to a best-effort delivery serv- 
ice in a connectionless environment at either the data link 
or network layers. 


Canadian public packet switched network. 


An X.25 term referring to the interface to users’ equipment 
as opposed to the DCE interface to the network. 


An IBM database package based on the relational model and 
the SQL query language. 


Database Management System. Software that allows the cen- 
tralized storage of data with multiple concurrent users, ac- 
cess control, and the use of a high-level data manipulation 
language such as SQL. 


Disconnect Confirm. A protocol data unit type in the OSI 
transport service. 


Daisy-Chained Faceplate. Abbreviation used in DECconnect. 


Document Content Architecture or Defense Communications 
Agency. Document Content Architecture is an IBM architec- 
ture similar in function to Digital’s Compound Document 
Architecture (CDA). The Defense Communication Agency is 
responsible for the Defense Data Network. 


See Data Country Code. 
See Data circuit-terminating equipment. 


Digital command language. The user interface in the VMS 


operating system. Similar to the C shell in the Unix operat- 
ing system. 


Direct Connect. Abbreviation used in DECconnect. 


Digital Data Communications Message Protocol. A data link 
protocol used in the Digital Network Architecture. Used for 
point-to-point links between nodes, either synchronous or 
asynchronous. An alternative data link protocol is Ethernet. 
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DDFF 


DDIF 


DDS 


DDXF 


deadlock 


DEBAM 


DEBET 


DEBNA 


DEC 


DECconnect 


DECdts 


DECmcc 


DECnet 


DECnet/DOS 


DECnet Router 


See Digital Document Final Format. 
See Digital Document Interchange Format. 
See Distributed Directory Service. 


DISOSS Document Exchange Facility. A Digital software prod- 
uct that allows transfer of data between Digital and IBM 
word processing environments. See also EDE. 


A term used in a concurrent environment. If one user 
holds a lock on a resource and is waiting for another re- 
source to free up and a second user has the reverse situ- 
ation, it is known as a deadlock. The deadlock must be bro- 
ken by arbitrarily picking one of the users and releasing its 
current lock. The deadlock is also known as a deadly em- 
brace. 


Model number for the Digital LAN Bridge 200. 


Model number for the Digital LAN Bridge 100 or 150 used 
for creating extended Ethernets. 


Digital BI-Bus Network Adaptor. Abbreviation used in DEC- 
connect. Ethernet controller for the BI-bus. 


Digital Equipment Corporation. The company prefers to be 
known as “Digital.” 


A Digital cabling architecture used for facilities wiring. 
Digital Distributed Time Synchronization Service. 


Digital Management Control Center. Digital software that is 
the implementation of the EMA management architecture. 


An implementation of the Digital Network Architecture by 
Digital, as opposed to implementations of DNA by other 
vendors. 


The version of DECnet for the PC-DOS or MS-DOS operating 
systems. 


A device that routes data between two portions of a DECnet. 
Could be a general-purpose computer such as a MicroVAX 
or a dedicated piece of hardware such as the DECSA. 


DDFF 11m DECnet Router 
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DECOM 


DECrouter 200 


DECSA 


DECserver 


DECtalk 


DECtdm 


DECUS 


DECwindows 


DECwindows 
Toolkit 


DED 


DEFTR 


DELNI 


Delta T 


DELUA 


DEMPR 


DECOM ia DEMPR 


A broadband Ethernet modem made by Digital. A DECOM- 
AA is a dual-cable modem; the DECOM-BA is a single-cable 
version. 


A dedicated router with eight asynchronous DDCMP ports 
and one Ethernet connection. 


Digital Synchronous Adapter. A general-purpose DECnet 
Router. The same piece of hardware also forms the basis 
for X.25 and SNA gateways. 


Digital terminal servers. 
A piece of Digital hardware that can “speak” ASCII files. 
Digital database software. 


Digital Equipment Corporation User Society. Digital user 
group. 


Digital’s implementation of the MIT X Window System. 


A set of utilities (such as default menus) developed by Digi- 
tal to supplement the basic X services. 


See dynamically established data link. 


Digital Frequency Translator. Digital’s frequency translator 
for single-channel broadband systems. 


Digital Local Network Interconnect. “Ethernet in a Can.” A 
multiport transceiver made by Digital. 


Delta time. Sniffer Analyzer indication of time elapsed be- 
tween consecutive packets on the network. Contrast to rela- 
tive time, which is the time that has elapsed since a particu- 
lar anchor packet was sent. 


Digital Local Unibus Adapter. An Ethernet controller made 
by Digital for UNIBUS processors. 


Digital Multiport Repeater. A piece of Digital networking 
hardware that can connect up to eight ThinWire Ethernet 


segments and optionally connect them to a backbone cable 
or DELNI. 
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DEMSA 


DEMWB 


DEPCA 


DEQNA 


DEREN 


DEREP 


DES 


designated router 


DESNC 


DESPR 


DESTA 


DFM 


DFS 


Digital MicroServer. A new generation of routers and gate- 
ways based on the MicroVAX II architecture as opposed to 
the PDP-based architecture of the DECSA. 


Digital Metrowave Bridge. Abbreviation used in DECcon- 
nect. Ethernet controller for the BI-bus. 


Digital PC Adapter. Abbreviation used in DECconnect. Eth- 
ernet Controller. 


Digital Q:Bus Network Adapter. A Digital Ethernet controller 
for Q-bus systems. 


Digital Repeater/Ethernet. Digital local repeater or a half of 
a fiber repeater. 


Digital Repeater. Digital Repeater meant to be used as a 
half of a fiber repeater and connected to the LAN Bridge 
100. 


Data Encryption Standard. One type of encryption scheme. 


A DNA routing concept. A given broadcast circuit (such as 
an Ethernet) will have a designated router, which is used by 
end nodes to forward all packets that will need routing deci- 
sions. 


Digital Secure Network Controller. Digital hardware control- 
ler to do encryption on an Ethernet. Requires the VAX Key 
Distribution Center software. 


Digital Single Port Repeater. Abbreviation used in DECcon- 
nect. Single port ThinWire repeater. 


Digital Station Adapter. Abbreviation used in DECconnect. 
ThinWire transceiver. 


Digital Frequency Multiplexor. A series of Digital products 
including X.25 asynchronous PADs and multiplexors. 


Distributed File Service (or System). A Digital product similar 
to the Network File System (NFS). Both allow remote files 
to appear as though they were locally mounted on a work- 
station, allowing diskless nodes. DFS uses the DNS name 
server. 


DEMSA 1m DFS 
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DFSCP 


DHCF 


DHV11 


DIA 


DIB 


Digital Document 
Final Format 


Digital Document 
Interchange 
Format 


Digital Network 
Architecture 


Digital Storage 
Architecture 


Digital Table 
Interchange 
Format 


directive 


director 


Directory Access 
Protocol 


Directory 
Information Base 


See Distributed File Service Control Program. 


Digital Host Command Facility. A Digital software product 
that, in conjunction with IBM’s Host Command Facility, al- 
lows an IBM terminal user to log onto a Digital network. 


A synchronous communications board for Qbus (MicroVAX) 
systems. Less powerful than the DSV11. 


Document Interchange Architecture. An IBM architecture for 
the interchange of messages. Usually used in conjunction 
with the Document Content Architecture (DCA). Imple- 
mented in a product called DISOSS. 


See Directory Information Base. 


CDA subset where a document has been encoded for a spe- 
cific output device. 


CDA specification for documents in revisable format. See 
Digital Document Final Format. 


Digital architectures for networking. DECnet is an imple- 
mentation of DNA. 


Digital architecture for mass storage devices and controllers. 


Part of CDA. The format for the storage and interchange of 
table-based information, such as spreadsheets. DDIF and 
DTIF work together. 


DNA network management term for an action to be taken 
by an entity. 


The DNA management entity that issues directives. NCP is 
an example of a director. 


X.500 protocol used for communication between a Directory 
User Agent and a Directory System Agent. 


X.500 term for the distributed database used to keep track of 
application entities, people, terminals, distribution lists, or 
other objects. 


DFSCP |i» Directory Information Base 
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SS SS 


Directory 
Information Tree 


Directory 
Management 
Domain 


Directory System 
Agent 


Directory System 
Protocol 


Directory User 
Agent 


DIS 


DISC 


DISOSS 


display object 


distinguished name 
distributed 


database 


Distributed 
Directory Service 


Distributed File 
Service 


X.500 term for the hierarchical namespace of objects con- 
tained in the Directory Information Base. 


An administrative group responsible for managing a por- 
tion of the directory information base. A directory manage- 
ment domain contains at least one directory system agent 
and zero or more directory user agents. 


X.500 term for the software that maintains and provides ac- 
cess to the Directory Information Base. 


X.500 protocol used for communication between directory 
system agents. 


X.500 term for the software that provides services to the 
user. The Directory User Agent uses the OSI ROSE proto- 
cols to communicate with one or more Directory System 
Agents. 


Draft International Standard. The state before a standard 
becomes an official international standard. At this point the 
standard is considered to be technically correct and only mi- 
nor corrections are anticipated. 


disconnect. 


Distributed Office Support System. An 
serves as a distributed library of documents. 
and DCA. 


IBM_ product that 
See also DIA 


Used in the OSI Virtual Terminal protocols. An abstract ob- 
ject used for communication between two systems. The dis- 
play object will map to a real object such as a video screen 
or printer. 


An X.500 concept for the unique name of an object derived 
from its location in the Directory Information Tree. 


Looks to the user like a single database but is in fact a col- 
lection of several different data repositories. 


Part of the MAILbus architecture that allows different forms 
of addressing to be supported. 


Digital product to make files on the network appear local. 
Similar to the Network File System. 


Directory Information Tree | Distributed File Service 
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Distributed File 
Service Control 
Program 


distributed 
naming service 


distributed 
systems 
management 


DIT 


DL 


DLAL 


DLC 


DMA 


DMB32 
DMD 
DMF32 


DML 


DNA 


DNA Naming 
Service 


DNS 


domain 


Domain Name 
System 


The program that implements the Distributed File Service. 
When a user mounts a foreign file system, he or she is issu- 
ing the command to DFSCP. 


Network-based service to allow a user to find the current 
address of a given resource, such as a printer or file system. 


The family of standards that Digital uses to manage the net- 
work. Includes EMA, event logging, and CMIP. 


See Directory Information Tree. 


Data Leads. Abbreviation used in DECconnect. DECserver 
with no Modem Control. 


Dual letter acronym listing. See also MLAL. 


Data Link Control. Sniffer Analyzer notation for data link 
layer information. 


Direct memory access. Allows a device on a computer to ac- 
cess main memory without a CPU interrupt. 


Digital BI bus-based communications controller. 
See Directory Management Domain. 
Digital UNIBUS-based communications controller. 


Data manipulation language. A language, such as SQL, used 
for retrieving and manipulating data in a database system. 


See Digital Network Architecture. 


A distributed naming service used heavily in DNA Phase V. 


See DNA Naming Service or Domain Name System. 


An area within which a particular service is performed. In 


a messaging domain, a message transfer agent for that do- 
main is able to deliver a message. 


TCP/IP service provider that translates names into IP ad- 
dresses for machines and users. 


Distributed File Service Control Program timp Domain Name System 
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Ssh 


domain specific 


part 


DOS 


DOS/VSE 


dpi 


DQS 


DR 


DRP 
DSA 


DSAP 


DSM 
DSP 


DSRI 


DSRVB 


DSS 


DSSA 


The portion of the OSI address space that is locally-adminis- 
tered. 


Digital Operating System. Microsoft operating system for 
IBM/PCs. 


Digital Operating System/Virtual Storage Extended. An IBM 
operating system used on 370 architecture mainframes. 


Dots per inch. A measure of the resolution of printers or 
scanners. 


Distributed Queuing Service. A Digital software product that 
allows print files submitted to a local queue to be automat- 
ically sent to a remote queue. 


Disconnect Request. A protocol data unit type in the OSI 
transport service. 


Digital Routing Protocol. 
See Digital Storage Architecture or Directory System Agent. 


Destination service access point. The address for the destina- 
tion user of a service. A remote IPX process would be con- 
sidered the DSAP from the point of view of the local data 
link module. 


See Distributed systems management. 
See Directory System Protocol or domain specific part. 


Digital Standard Relational Interface. A Digital standard call- 
ing sequence for database applications. Allows any DSRI- 
compatible user interface to access any DSRI-compatible 
data repository. 


Digital terminal server model number. 


Distributed system services. A family of Digital software in- 
cluding the Digital Name Service (DNS) and the Distributed 
File Service (DFS). 


Digital Distributed System Security Architecture. Digital pro- 
gram that includes network security. 


domain specific part im DSSA 
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DST 


DSV11 


DT 


DTE 


DTF 


DTIF 


DU 


DUA 


Dual Attachment 


Station 


dual porting 


DUI 


DWF 


dynamically 
established data 
link 


E.163 


DST 11m E.163 


Destination address. Sniffer Network Analyzer abbreviation 
for destination address. 


A high-performance Qbus synchronous communications 
board. 


Data. A protocol data unit type in the OSI transport serv- 
ice. 


See Data terminal equipment. 


Data transfer facility. Digital software products that run in 
both VMS and IBM environments and permit the integra- 
tion of both types of file systems from within the Digital 
Command Language. 


See Digital Table Interchange Format. 


Data unit. Part of the OSI File Transfer Access and Manage- 
ment (FTAM) protocols. 


See Directory User Agent. 


FDDI term for a node that is attached to both the primary 
and secondary fiber optic cables (as opposed to a node that 
is connected to the ring via a concentrator). 


Making a disk drive available to two different computers, as 
in the case of a VAX Cluster. 


Data Unit Identifier. A packet identifier used for reassembly 
at the network layer. 


data waiting flag An LAT state variable indicating that 
there are slots at the session layer ready to be sent over a 
virtual circuit. 


Digital software product for transfer of WPS documents into 
other formats. 


A DNA Phase V capability to establish a link over connected 
oriented subnetworks such as ISDN, X.25, X.21, or the public 
switched telephone network. 


CCITT numbering scheme for public switched telephone 
networks. 
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E.164 


Easynet 


EBCDIC 


ECC 


Echo 


ECL 


ECMA 


ECO 


ED 


EDE 


EDI 


EDIFACT 


EDT 


EGP 


EIA 


EIA-423 


CCITT standard for numbering in an ISDN environment. 


Expedited Acknowledge. A protocol data unit type in the OSI 
transport service. 


Digital’s internal communications network. 


Extended Binary Coded Decimal Interchange Code. A_charac- 
ter code scheme used in IBM environments. See also ASCII. 


Error-correcting code. Feature of the Digital Storage Archi- 
tecture used in error detection. Similar to a CRC. 


A maintenance protocol in XNS. Used to echo information 
back across the network and thus test the connection. 


See End Communication Layer. 


European Computer Manufacturers Association. A leading 
European standards body. 


Engineering change order. Digital term for a minor change 
to a piece of software. ECOs are more granular and occur 
between major or minor revisions. 


Expedited Data. A protocol data unit type in the OSI trans- 
port service. 


Electronic Document Exchange. A Digital product that allows 
revisable form document transfer with DISOSS libraries. 
See also DDXF. EDE-W is a similar program for document 
interchange between Wang and Digital systems. 


See Electronic Data Interchange. 


EDI for Administration, Commerce, and Trade. Emerging in- 
ternational EDI standard. 


Standard Digital editor on the VMS operating system. 


Exterior Gateway Protocol. A means for updating routing ta- 
bles in the Internet environment. 


Electronic Industries Association. Trade association. 


Standard interface definition for serial devices. 


E.164 timp ElA-423 
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EJ 


Electronic Data 
Interchange 


ELK 


EMA 


EMACS 


Email 


EMS 


End 
Communication 
Layer 


endian 


end node 


end system 


ENSDU 


Enterprise 
Management 
Architecture 


entity 


EJ im entity 


Etherjack. Abbreviation used in DECconnect. Terminator 
for transceiver cable. 


A structured form of text exchange used to exchange infor- 
mation such as purchase orders. See X.12. 


External Link Interface. A programming library that allows 
an application to link to a Videotex (VTX) system on a re- 
mote DECnet node. 


See Enterprise Management Architecture. 


An extensible editor developed at M.I.T. based on the LISP 
programming language. 


Electronic mail. Software/networks that allow the exchange 
of messages between users. 


Enterprice Management Station. An early version of the 
DECmcc software. Consists of the four packages for SMS 
(Site Management Station) plus the NMYCC/DECnet Monitor. 


The DNA transport layer. 


How a computer stores a multi-octet piece of data (ie., a 
four-byte integer). See big endian and little endian. 


A DECnet term referring to a member of the network that 
can do everything but route packets through on behalf of 
other nodes. Ultrix, MS-DOS, and third-party implementa- 
tions of DECnet are all end nodes. 


OSI term for a nonrouting node. Equivalent to end node. 


Expedited Network Service Data Unit. From OSI Network 
Service Definition. 


A Digital architecture for network management user inter- 
faces that can work with multiple displays and protocols. 
DECmcc is the implementation of this architecture. 


DNA network management term for a manageable piece of 
a distributed system. 
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EOF 


EOM 


epoch 


ER 
ERCO 


Error 
ES 
ES-IS 


ESH PDU 


Ethernet 


Ethernet controller 


Ethernet Version 
2.0 


ETHERnim 


End of file. A mark that tells the file system that it has 
reached the end of a file. 


End of message. A mark put into network traffic to indicate 
logical boundaries on a stream interface. 


Term used in the DNA Naming Service. Epochs control the 
replication of directories. After a disaster, a new epoch is 
declared preventing previously initiated skulks from inter- 
fering with the reconstruction of the directories. 


Error. A protocol data unit type in the OSI transport serv- 
ice. 


Entry rules control object. Provides validation checks for the 
OSI virtual terminal service in field mode. 


XNS protocol used to report errors across a network. 
See End system. 


End system to intermediate system. ISO 9542 routing ex- 
change protocol. Includes end and intermediate system 
hello messages. 


End System Hello PDU. From OSI Network Service Defini- 
tion. 


A data link protocol jointly developed by Intel, Xerox, and 
Digital and subsequently adopted by the IEEE as a standard. 
Several upper-layer protocols, including DECnet, TCP/IP, 
and XNS, use the Ethernet as an underlying transport 
mechanism. Ethernet is to be contrasted with other data 
link protocols such as the token ring, DDCMP, and SDLC. 


A device controller that gives the computer access to the 
Ethernet services. Typically, the CSMA/CD protocols are 
built into the controller so the CPU does not have to worry 
about the details of the protocol. 


The second version of the original specification for Ether- 
net, which differs slightly from the IEEE 802.3 standard. 


Ethernet Network Integrity Monitor. A Digital product for 
monitoring Ethernets. 


EOF ia» ETHERnim 
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Ethertype 


EVD 


event dispatcher 


event log 


event sink 


exclusive lock 


executable image 


External Data 
Representation 


external name 


F.69 

F.110 
F.160 
F.200 
F.201 
F.300 


F.401 


F.410 


Ethertype iim F.410 


Field in version 2.0 of Ethernet that indicates the type of 
user (DECnet, NetWare, or TCP/IP, for example). 


See Event dispatcher. 


A module on a node responsible for accepting event reports 
from different modules and dispatching them across the 
network to different event sinks. 


A record of significant events kept in the director. 


The destination in the network where significant events 
should be sent. Examples of a sink are a file, a program, 
and a terminal. 


A lock on data that prevents other users from accessing it. 
Used for write operations. In contrast to a shared (read) 
lock. 


A program that is ready to run on an operating system. A 
program starts as source code and gets compiled to generate 
object code. The object code is then linked to form an exe- 
cutable image. 


Presentation layer protocol developed by Sun Microsystems 
as part of NFS. 


The external representation of a name (that seen by hu- 
mans) in the DNA Naming Service. 


CCITT standard for telex addresses. 

CCITT standard for maritime mobile service. 

CCITT standard for international public facsimile services. 
CCITT standard for teletex services. 

CCITT standard for internetwork teletex and telex services. 
A set of CCITT recommendations for Videotex systems. 


CCITT standard for the naming and addressing public mes- 
sage-handling services. 


CCITT standard for the public message transfer service. 
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F.415 


F.420 


F.421 


F.422 


F.500 


F.60 


FADU 


FAL 


fault tolerance 


fax 


FC 


FCL 


FCPLT 


FCS 


FDDI 


FFFF 


CCITT standard for intercommunication with public physi- 
cal delivery services. 


CCITT standard for the public interpersonal messaging serv- 
ice. 


CCITT standard for communication between the X.400 inter- 
personal messaging service and the telex service. 


CCITT standard for communication between the X.400 inter- 
personal messaging service and the telex service. 


CCITT standard for international public directory services. 
CCITT standard for telex services. 


File access data unit. The unit of access in the OSI FTAM 
service. 


See File Access istener, 


An attribute of a computer system that reflects its degree of 
tolerance to hardware and software failures while continu- 
ing to run. 


Facsimile. A messaging service based on transmitting bit 
maps of 200 dots per inch across dial-up telephone lines. 


Frame control. Token ring field that indicates whether the 
packet is a MAC-layer management packet (i.e., a token, bea- 
con, AMP, or SMP) or is carrying LLC data. 


Forms and Command Line module. Presentation module in 
DECmcec. 


Faceplate. Abbreviation used in DECconnect. 


Frame check sequence. A mechanism like a CRC or check- 
sum to guarantee the integrity of a packet of data. 


See Fiber Distributed Data Interface. 


15 15 15 15. A hexadecimal number. Hexadecimal is base 
16 numbering in which the symbols A through F are used 
to represent the digits 10 through 15. 


F.415 i FFFF 
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ee ——————ee 


FFT 


Fiber Distributed 
Data Interface 


field 


FI.FMD 


File Access Listener 


file cache 


File Sharing 
Services 


file system 


FIMS 


finite state 
machine 


FLASH/IMS 
Programming 
Interface 


floating point 


FFT imp floating point 


Final form text. A version of IBM’s Document Content Ar- 


chitecture (DCA). 


A 100-Mbps fiber optic local area network standard based on 
the token ring. 


A term used in designing forms-based systems such as data- 
base applications. A field is a portion of the screen used for 
data input that is automatically mapped to a variable. The 
field may have attributes such as reverse video or default 
values. 


Function Interpreters for Function Management Data. IBM’s 


presentation layer protocol for SNA. 


A process invoked across the network by a user trying to 
access data on nonlocal systems using Digital’s Data Access 
Protocol. A FAL is a remote DAP-speaking process invoked 
by the Record Management Services on the local node. 


Keeping portions of files in main memory. When the com- 
puter requests data, if it is in the cache, it alleviates the 
need to refetch it from the much slower disk drive. 


Digital term for a distributed file service. 


The portion of an operating system that is responsible for 
storing and retrieving pages of data onto a disk. 


See Form Interface Management System. 


A way of describing a network module as a set of states that, 
based on inputs and conditions, perform transitions to 
other states and outputs. 


DECnet/SNA software product layered on top of the LUO Ap- 


plication Programming Interface allows access to IBM IMS 
database systems. 


A native data type on most operating systems. A floating 
point number is one that can have numbers after the deci- 
mal point, in contrast to an integer, which cannot. 
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ES SS SSR RC 


flow control 


FM 


Form Interface 
Management 
System 


fourth-generation 


language 


FPI 


frame 


front end 


FS 


FSZ 


FTAM 


full-duplex 


full name 


A set of rules that allows a module to control the flow of 
data from another node. Flow control prevents limited 
buffer space from being filled, which means additional data 
received has no place to be stored. 


See Function module. 


Draft ISO standard for forms management. 


A group of new languages often linked with database pack- 
ages such as Ingres or Oracle. In contrast with FORTRAN 
and other third-generation languages. 


See FLASH/IMS Programming Interface. 


A series of bytes of data encapsulated with a header. The 
data link layer sends frames of data back and forth. 
“Frame” is often used interchangeably with “packet,” al- 
though technically a packet refers to data from the network 
layer of the protocol stack. A packet is thus usually con- 
tained inside of a frame. 


A program with which a user interacts. The front end sends 
off requests to the back end for data. 


Frame status. Token ring field that indicates whether the 
address on a packet has been recognized by a station and if 
the data have been copied. 


Fixed Part Size Abbreviation used in DAP to refer to the 
header portion of a variable record file. 


File Transfer, Access and Management. The OSI application 
layer service that provides access to virtual file stores on for- 
eign systems. Similar to the DNA DAP protocols in purpose. 


File transfer protocol. An upper-layer TCP/IP service for 
copying files across the network. 


A data communications term that indicates both ends of a 
communications link can transmit simultaneously. Con- 
trasted with half-duplex, where only one side can transmit 
at one time. 


A unique, unambiguous name in the namespace. 


flow control iim full name 
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function 


function module 


GAP 


Gateway 


Gbyte 


GGP 


GID 


gigabyte 


GKS 


GKS-3D 


global entity 


GOSIP 


function 1m GOSIP 


Takes a piece of data as input and returns a value. For ex- 
ample, the query language has functions that can accept a 
date and return the day of the week that the date falls on. 


A part of the EMA architecture. The function module is re- 
sponsible for high-level management functions, such as con- 
figuration, security, or historical event reporting. See also 
access module and presentation module. 


Gateway Access Protocol. A protocol used by applications 
software to access DECnet Gateways. The 3270 access rou- 
tine, for example, would use GAP to access an SNA Gateway. 


There are two somewhat conflicting definitions of gateway, 
both used in networking. In the general sense, a gateway is 
a computer that connects two different networks together. 
Usually, this means two different kinds of networks such as 
SNA and DECnet. In TCP/IP terminology, a gateway con- 
nects two separately administered subnetworks, which may 
or may not be running the same networking protocols. 


Gigabyte. One billion bytes of data. 


Gateway to Gateway Protocol. An obsolete interior protocol 
in TCP/IP similar in functionality to RIP. 


Group identification. 


One billion bytes of data. 


. See Graphical Kernel System. 


Graphical Kernel System for Three Dimensions. 3D extensions 
to the GKS standards. 


The top level of the entity tree for management purposes. A 
node is an example of a global entity, with subentities in- 
cluding modules such as routing, MOP, and LAT. 


Government OSI Protocols. Government-specified subset of 
the international OSI standards. 
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granularity 


Graphical Kernel 
System 


H4000 


H4000-BA 


half-duplex 


handle 


HASP 


HDLC 


HDR 


heap 


HEPnet 


heterogeneous 


heterogeneous 
network 


A term used in lock managers on an operating system. 
When the lock manager locks an entire file, this is locking 
with course granularity. When the lock manager locks a 
single record, this is fine granularity. Granularity is one of 
the factors that influences the performance of a particular 
application such as a DBMS. 


ISO standard for the creation and manipulation of 2D ob- 
jects. 


Digital’s baseband Ethernet transceiver. 
Ethernet transceiver for DELNI and DEMPR units. 
See full-duplex. 


A number used to refer to a file or directory that is being 
remotely accessed on the network. 


Houston Automatic Spooling Program. One of the original 
implementations of the remote job entry function on IBM 
equipment. Still used in conjunction with bisync as a low- 
est common denominator of interoperability. 


High-level data link control. ISO’s data link protocol. Used 
in OSI and X.25 networks. Alternative protocols include 
SDLC in the IBM networks and DDCMP in the Digital net- 
works. 


Historical Data Recorder. Function module in DECmcc. 


A storage structure for data, where data are not placed in 
any particular order, requiring a scan of the entire table for 
every retrieval. 


High Energy Physics network. 
Different. 


A network consisting of different network protocols or 
kinds of computers. A network combining SNA and DNA 
protocols using an SNA gateway to connect the two is a het- 
erogeneous network. 


granularity iim heterogeneous network 
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hierarchical 
database 


hierarchical 
routing 


Hierarchical 
Storage Controller 


HL 
homogeneous 


hooks 


hop 


host 


HSC 


hub 


1.120 
1.230 
1.240 


1.250 


A database that structures data as a hierarchy instead of in 
tables. Programmers then navigate the hierarchy to retrieve 
a particular row of data. IMS is an example of a hierarchi- 
cal database system. 


Routing based on domains. Interdomain routers are re- 
sponsible for getting data to the right domain. There, an 
intradomain router takes responsibility for routing within 
the domain. 


Standalone disk and tape controller used in clusters using 
the CI bus. The HSC is actually a modified PDP computer 
that has been optimized as a mass storage controller. 


High-Loss Transceiver Cable. DECconnect abbreviation. 
The same. 


Programming technique. Allows a programmer to add new 
code to an existing program. The existing program has 
hooks that execute any additional code. 


A term used in DECnet routing calculations. A hop is one 
data link. A path to the final destination on a DECnet is a 
series of hops away from the origin. Each hop has a cost 
associated with it, allowing the calculation of the least cost 
path. 


A computer that provides services directly to users (as op- 
posed to a behind-the-scenes dedicated server). 


See Hierarchical Storage Controller. 


A device connected to several other devices. In ARCNET, a 
hub is used to connect several computers together. In a 
message-handling service, a hub is used for the transfer of 
messages across the network. 


CCITT description of ISDN. 
Description of ISDN bearer services. 
Description of ISDN teleservices. 


Description of ISDN supplementary services. 


hierarchical database im 1.250 
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1/O 
IBM PC LAN 
IBM Token-Ring 


IBM Token-Ring 
Adapter 


ICD 


ICMP 


icon 


idempotent 


IDI 


IDL 


IDMS 
IDP 


IEEE 


IEEE 488 


ILV 


IMS 


See Input/Output. 
IBM PC network using broadband. 
IBM token ring network. 


Token ring controller card sold by IBM. 


See International Code Designator. 


Internet Control Message Protocol. Protocol used by the IP 
layer of TCP/IP for exchanging routing control messages. 


A small pictorial object on a workstation used to represent a 
closed window. The user points to the icon, clicks the 
mouse button, and a window opens. 


A characteristic of an operation where it will yield the same 
result if it is executed more than once. Change X to 25 is 
idempotent. Add 25 to X is not. 


Initial domain identifier. Part of an OSI address. Goes after 
the authority and format identifiers. For example, the IDI 
for a telephone address might be the country code. 


identifier list Digital Naming Service attribute used for ac- 
cess control. A user’s IDL is compared with the ACL of the 
object requested to determine if access is granted. 


Cullinet’s database management system for IBM systems. 
See Internetwork Datagram Protocol or initial domain part. 


Institute of Electronic and Electrical Engineers. A leading 
standard-making body in the United States responsible for 
the 802 standards for local area networks. 


IEEE standard for real-time data acquisition. 


indicator, length, value Way of encoding parameters in 
DECmcc. 


Information Management System. Database management 
software from IBM based on the hierarchical data manage- 
ment model. 


1/0 ep IMS 
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index 


information 
manager 


Ingres 


initial domain part 


initialization 


packet 


input/output 


Integrated Services 
Digital Network 


interactive 
terminal 


interchange key 


internal name 


International Code 
Designator 


International 
Organization for 
Standardization 


A direct access method to data. An index has a key value 
and a pointer to the row of the table that contains data with 
the key value. An index can be a primary index, where it is 
part of the storage structure of the actual table, or a secon- 
dary index, which is a separate table in the database with 
pointers to the base table. 


A module within the DECmcc software responsible for 
scheduling requests received from management modules. 


A popular relational database management system that runs 
on a variety of operating system platforms. A famous nine 
teenth-century French painter. 


The first part of an ISO address. The IDP is made up of an 
Authority and Format Indicator and an Initial Domain Iden- 
tifier. See also domain specific part. 


A token ring packet used when a node joins the network. 


Generic term for transfer of data from main memory to 
either a disk drive, terminal, printer, or other device. 


An emerging international communications standard that 
allows the integration of voice and data on a common trans- 
port mechanism. 


A traditional terminal with a human being hitting keys. 
Contrast with application terminal. Used in LAT. 


A cryptographic key shared by two or more parties. 


The internal representation of a name as stored by the DNA 
Naming Service. 


An ISO-administered four-digit unique ID based on organi- 
zations (as opposed to the Data Country Code which is 
based on geographic location). 


International standards-making body responsible for the 
Open Systems Interconnection network architecture. 


index im International Organization for Standardization 
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International 
Telegraph and 
Telephone 
Consultative 
Committee 


Internet 


internetwork 


internetwork 
address 


Internetwork 
Datagram Protocol 


Internetwork 
Protocol 


interprocess 
communication 


IOCTL 


IOP 


IP 
IPC 


IPDS — 


IPMS 


English name for the CCITT. 


A collection of networks that share the same namespace and 
use the TCP/IP protocols. The Internet consists of more 
than 5000 interconnected networks. The Internet should 
not be confused with internet (lowercase) which refers to 
any collection of networks with a path between them. 


A collection of data links and the network layer programs 
for routing among those data links. 


An address consisting of a network number and a local ad- 
dress on that network. Used by the network layer for rout- 
ing packets to their ultimate destination. 


Network layer protocol in XNS. 


Network layer protocol in TCP/IP. 


Communication between two processes by passing parame- 
ters and return values. Remote calls are a special case of an 
interprocess communication mechanism. 


I/O Control. Unix function call used to control a device. 


Input/output processor. Term used by Unix-based minicom- 
puter manufacturers to refer to the I/O subsystems. 


See Internetwork Protocol. 
See Interprocess Communication. 


Intelligent Printer Data Stream. A component of IBM’s Sys- 
tem Application Architecture (SAA). 


Interpersonal messaging service The part of the X.400 proto- 
cols that defines what the header of a message looks like. 
The message transfer service (MTS) then defines what the 
envelope the message goes in looks like. 


International Telegraph and Telephone Consultative Committee iim IPMS 
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IRDS 


IS 


ISAM 


ISDN 


ISH PDU 


IS-IS 


ISO 


ISPF 


ISV 


ITT 


ITU 


JCL 


JES 


job queue 


JTM 


kbps 


IRDS im» kbps 


Information Resources Dictionary System. An ANSI and ISO 
standard for data dictionaries. 


Intermediate System OSI term for a router. 

Indexed sequential access method. A file structure that al- 
lows random access to data via an index then sequential ac- 
cess to data after that. 


See Integrated Services Digital Network. 


Intermediate System Hello PDU. From OSI Network Service 
Definition. 


Intermediate System to Intermediate System An OSI protocol 
for routers to dynamically exchange topology information. 


See International Organization for Standardization. 


Interactive System Productivity Facility. An IBM product that 
runs on the TSO and CMS user environments. ISPF pro- 
vides a series of menus (dialogues) for use on a 3270 termi- 
nal that allow the user to bypass a command language inter- 
face to the operating system. 


Independent Software Vendors. Third party software devel- 
opers. Sometimes known as VARs, OEMs, or third party 
software developers. 


Invitation to Transmit. ARCNET equivalent of a token. 


International Telecommunications Union UN agency that ad- 
ministers the CCITT. 


Job Control Language. Language used for batch processing 
on IBM mainframes. 


Job Entry Subsystem. Types of processes on IBM main- 
frames that accept JCL. 


A method of letting multiple requests for a scarce resource 
queue up, as in the case of a print queue. 


Job transfer and manipulation. An OSI layer 7 standard 
similar in function to a remote job entry (RJE) service. 


Kilobits per second. Thousand bits per second. 
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kbytes 


KDC 


keep alive message 


Kerberos 


Kermit 


kernel 


LA100 


LAPB 


LAPX 


LAST 


LAT 


latency buffer 


Kilobytes. Thousands of bytes of information. 
See VAX Key Distribution Center. 


A message sent over a network link during periods when 
there is no traffic between users. The message tells the re- 
mote node this computer is still in operation. 


A component of MIT’s Athena project. Kerberos is the secu- 
rity system, based on symetric key cryptography. Contrast 
with the RSA public key cryptography techniques. 


A popular file transfer protocol developed by Columbia Uni- 
versity. Because Kermit runs in most operating environ- 
ments, it provides an easy method of file transfer. 


A term used in operating systems. The kernel shields the 
low-level functioning of the operating system from high- 
level interfaces such as user shells. 


A Digital dot matrix printer commonly found in machine 
rooms as console printers. 


Local Area Disk Driver. Protocol used for remote booting of 
PCs in DECnet/DOS. 


Local area network. Usually refers to Ethernet or token ring 
networks. 


Link access procedure. A protocol for accessing a data link. 


Examples are LAP B used in the X.25 environment and LAP 
D used in the ISDN environment. 


Link Access Procedure, Balanced. A subset of the HDLC data 
link standards. 


Link Access Procedure, Extended. Similar to LAPB but with 
extended sequence numbers. 


Local Area System Transport. Protocol for remote booting in 
DECnet/DOS. 


See Local Area Transport. 
Token ring concept. The buffer is maintained by the active 
monitor and is used to compensate for variations in the 


speed of data on the network. 


kbytes tim latency buffer 
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LAVC 


LF 


LI 


little endian 


LL 
LLC 


LNO3 


Local Area 
Transport 


LocalTalk 


locking 


lock manager 


logical 


Logical Link 
Control 


Local Area VAX Cluster. An adaptation of the System Com- 
munication Architecture (SCA) to run over the Ethernet in- 
stead of a CI bus. Used to enable MicroVAXs to operate as 
diskless nodes. 


line feed 


Length Indicator. Used in the ES-IS protocols in the OSI net- 
work layer. 


A multiple-octet piece of data where the lowest addressed 
octet is the least significant. 


Low-Loss Transceiver Cable. DECconnect abbreviation. 
See Logical Link Control. 


Digital’s first eight ppm laser printer. LNO3 is a proprietary 
language that has been superseded by the Scriptprinter, 
which uses the same engine and the Postscript page descrip- 
tion language. 


Protocol developed by Digital for communication between 
terminal servers and hosts on an Ethernet. 


Data link developed for AppleTalk that uses ordinary 
twisted pair cabling. 


Preventing another user from accessing a piece of data. 


Part of the operating system that ensures multiple requests 
for the same data are not serviced in a way that will damage 
the integrity of the data. 


Without reference to physical details. Asking for data in a 
logical manner, for example, means not having to know 
where the data are located or how to get them. 


The upper portion of the data link layer defined in the IEEE 
802.2 standard. The logical link control layer presents a uni- 
form interface to the user of the data link service, usually a 
network layer. Underneath the LLC sublayer of the data 
link layer is a media access control sublayer. The MAC 
sublayer is responsible for taking a packet of data from the 
LLC and submitting it to the particular data link being used 
(such as Ethernet or token ring). 


LAVC imap Logical Link Control 
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Logical name 


LT™M 


LU 


LU 6.2 


MAC 


MAC-layer bridge 


mail-11 


mailbox 


MAILbridge Server 


MAILbus 


Maintenance 
Operation Protocol 


management 
description 


language 


A Digital Command Language feature that allows the logical 
naming of devices, permitting a layer of separation between 
the physical configuration of a system and the logical view 
seen by the user process. Similar to the Unix concept of an 
environmental variable. 


Link state packet. Routing control information message ex- 
changed in a Phase V DECnet. 


LAN Traffic Monitor. Digital software that uses a LAN 
Bridge 100 to monitor an Ethernet network. 


Logical unit. .An IBM term in SNA which refers to a soft- 
ware or microcode program that uses the network. For ex- 
ample, a terminal connected to a 3274 cluster controller is 
represented by an LU2 on that cluster controller. 


Logical Unit 6.2. See APPC. 
See Medium Access Control. 


A device that connects two or more similar data links in a 
way that is transparent to the user of the data link service 
(the network layer). 


The original mail routing protocol used on VMS mail. Mail- 
bus is a more modern message-handling architecture. 


A VMS concept used for interprocess communication. Proc- 
esses leave messages for each other in a mailbox. 


A series of SoftSwitch products used for connecting differ- 
ent message handling environments. 


A Digital architecture that provides a common message-han- 
dling system on a DECnet. 


Special-purpose DECnet protocol used for remote booting 
on the network and attaching a console onto a station re- 
motely. 


A formal language for describing the management. informa- 
tion and operations for an entity. See also management speci- 
fication. 


Logical name iim management description language 
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management 
information 
repository 


management 
module 


management 
specification 


management 
specification 


language translator 


MAP/TOP 


marshalling 


master replica 


MAU 
MB 
Mbps 
Mbytes 


MC 


MCC 
MCI 

MCI Mail 
MD 


Media Interface 
Connector 


A component of the DECmcc software. The MIR keeps in- 
formation about entity classes, entity instances, entity attrib- 
utes, and miscellaneous data. 


One of the plug-in modules in DECmcc. There are three 
types of management modules: function modules, access 
modules, and presentation modules. 


A formal lanaguage used in DECmcc to specify the struc- 
ture, interfaces, and attributes for an entity class. 


A DECmcc program that loads a management specification 
into the DECmcc dictionary. 


Manufacturing Automation Protocols/Technical Office Protocols 
Subsets of OSI promoted by General Motors and Boeing. 


Term used in RPC calls. Marshalling is taking a local proce- 
dure call and packaging it into a form for sending over the 
network. 


The copy of a directory in the DNA Naming Service that can 
perform all actions, including child directory creations and 
deletions. See also read-only replica and secondary replica. 


See multistation access unit. 


Megabytes. Million bytes of information. 
Million bits per second. 
Megabytes. Million bytes of information. 


Modem Control. DECconnect abbreviation. DECserver with 
Modem Control 


Management Control Center. See DECmcc. 
Long distance telephone company. 
Commercial electronic messaging service. 
See management description language. 


The optical fiber connector that connects the fiber to the 
FDDI controller. 


management information repository im- Media Interface Connector 
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Medium Access 
Control 


MEN 


Message-Handling 
Service 


message-handling 
system 


Message Router 


Message Router 
Facsimile Gateway 


Message Router 
X.400 Gateway 


message transfer 
agent 


MHS 
MIC 


MICE 


MicroVAX 


Minitel 


MIP 


The bottom half of the ISO data link layer. See also Logical 
Link Control. 


Management event notification. Part of DECnet Phase V net- 
work management. Used for sending information about 
events across the network. See MICE. 


Action Technologies’ product for message handling, bun- 
dled into Novell networks as NetWare MHS. To be con- 
trasted with the generic message handling service, which in- 
cludes X.400 and other standards. 


A system of protocols such as X.400 used to exchange mes- 
sages such as electronic mail. 


Digital product that implements the MAILbus architecture. 
Message Router is analogous to the X.400 Message Transfer 
Agent. 


Digital product that links the Message Router to Group III 
facsimile machines. 


Digital product that connects X.400 and Message Router. 

An X.400 term referring to the collections of network mem- 
bers responsible for transferring messages. The final MTA 
delivers the message to a user agent which is concerned 


with reading, editing, and other types of interaction with 
the end user. 


See Message-Handling Service or message-handling system. 
See Media Interface Connector. 


Management information, control, and exchange. A DECnet 
Phase V network management protocol. See also MEN. 


A series of Digital processors usually used as workstations or 
small servers that compete in the marketplace with Sun and 
Hewlett-Packard/Apollo. ~ 


A French terminal used for Videotex applications. 


Million instructions per second. A measure of the speed of a 
CPU. 


Medium Access Control ta) MIP 
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MIPS 


MIR 


mirrored 


MIS 


MLAL 


MM 


MMJ 


MMS 


modem 


modified modular 
jack 


MONITOR 


monitor bit 


MIPS ima monitor bit 


Million instructions per second. A measure of CPU process- 
ing power. Different machine architectures use different in- 
struction sets, so comparison of MIPS across architectures is 
highly misleading. MIPS also do not take into account the 
speed of other resources on a system such as bus speeds, 
I/O processor speed, disk drive throughput, or main mem- 
ory access times. 


See Management information repository. 


A disk drive is mirrored when two identical copies of the 
data are kept on two different disk drives. If one fails, the 
other can keep operating. 


Management Information System. A database system used to 
provide information to managers in an organization. The 
term has come to refer to the department in an organiza- 
tion responsible for computing. 


Multiletter acronym listing. 
See management module. 
See modified modular jack. 


Manufacturing messaging service. Part of the MAP protocols 
used for communicating with robots, programmable con- 
trollers, and other devices. 


Modulator/demodulator. A device that takes digital data 
from a computer and encodes it in analog form for trans- 
mission over a phone line. Modems are also used to con- 
nect computers to an analog broadband system. 


A DECconnect term for the connection on the faceplate used 
to connect a data cable. 


A VMS tool used to examine the current status of a system. 


Token ring concept. The monitor bit is flipped by the active 
monitor to prevent a frame of priority greater than 0 from 
circulating continuously. 
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MOP 


mount 


mouse 
MPR 

MPT 

MR 
MR/FAX 
MR/P 
MRS 

MR/S 
MR-TELEX 
MRX 


MSCP 


MS-DOS 


MS-NET 


MSL 


MTS 


See Maintenance Operation Protocol. 


Term used in the Network File System for making a remote 
file system appear as if it were a local disk drive. A Digital 
Distributed File Service Control Program (DFSCP) command 
to take a remote file system and make it appear to be locally 
attached. 


A pointing device used on workstations. 

See multiport repeater. 

See multiport transceiver. 

See Message Router. 

See Message Router Facsimile Gateway. 

Message Router PROFS Gateway. 

Maximum Reon Size Abbreviation used in DAP. 

Message Router SNADS Gateway. 

Message Router TELEX Gateway. 

See Message Router X.400 Gateway. 

Mass Storage Control Protocol. The protocol used by HSC 
storage controllers to communicate with device drivers on 


the VAXs in a cluster. 


Microsoft-Digital Operating System. Méicrosoft’s version of 
PC-DOS. 


Microsoft network architecture that includes the NetBIOS 
and SMB protocols. 


See Management specification language translator. 
See Message transfer agent. 
Message Transfer Part. See Q.701. 


Message transfer service. The X.400 protocols that govern 
the exchange of envelopes of information. The IPMS de- 
fines the content of the envelope. 


MOP. iim =MTS 
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multicast 


multicasting 


multilink end node 


multipoint 


multiport repeater 


multiport 
transceiver 


multisegment 
Ethernet 


multistatement 
transaction 


multistation access 
unit 


An address to which several nodes will respond. Contrast to 
broadcast, where all nodes on a network will respond. 


A term used in Ethernet addressing. A multicast address is 
a group address meant for a certain subset of users on the 
Ethernet. LAT nodes communicate their current status with 
each other using a multicast address. To be contrasted with 
a broadcast address that is received by all users on the Eth- 
ernet. 


An end node that has more than one connection to the net- 
work. The end node may send and receive data over any of 
the links but will not route traffic for other nodes. 


A data link layer concept in which multiple nodes share a 
common physical medium. In a multipoint situation, a sin- 
gle node is the controller of the line and polls all tributaries 
periodically to see if they wish to send data. This is in con- 
trast to multiaccess media like Ethernet where any node 
may send without permission. 


An Ethernet repeater, typically for thinwire networks, that 
connects several segments together into a multisegment 
Ethernet. 


Several Ethernet transceivers built into one device. Can op- 
erate as a concentrator on a cable or as a stand-alone Ether- 
net (known as Ethernet in a can). 


Several segments of Ethernet connected together with re- 
peaters. All signals broadcast on a multisegment Ethernet 
are received by all other nodes. This is in contrast to the 
extended Ethernet, where the MAC-layer bridge forwards 
only those packets destined for the other Ethernet. 


Several different interactions with the database that are 
grouped into a single transaction. If any one of the opera- 
tions are not carried out because of a user abort or system 
crash, the entire transaction is rolled back. In a multistate- 
ment transaction all or none of the operations is carried 
out. 


Token ring device used to connect several stations to the 
ring. Similar to the multiport transceiver for the Ethernet. 


multicast im multistation access unit 
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SS 


multitasking 


multithreaded 


MUxXserver 


MVS/TSO 


NAK 


Named Pipes 


name server 


namespace 


Namespace 
Creation Time 
Stamp 


NAS 


National Bureau of 
Standards 


National Institute 
for Standards and 
Technology 


When an operating system (and microprocessor) maintains 
its position in several tasks simultaneously. The microproc- 
essor alternates between the different tasks under control of 
the operating system scheduling process. Unix is an exam- 
ple. 


An operating system feature that allows a process to main- 
tain several threads of execution, each under the control of 
the parent process. OS/2 is an example. 


A Digital product that combines a multiplexer and a termi- 
nal server in one device. Allows remote multiplexed traffic 
to access LAT-based services. 


Multiple virtual storage/time sharing option. MVS is an IBM 
operating system. TSO is the interactive subsystem, as op- 
posed to a system like JES used for batch processing. 


Negative acknowledgment. Response to nonreceipt or receipt 
of a corrupt packet of information. 


A process-to-process protocol that allows a full-duplex com- 
munication path to be maintained. The pipe is the end- 
point of the communication path through which a process 
gains entry to the function. Names are maintained and reg- 
istered on the network, allowing a pipe to access services. 


A node containing one or more active clearinghouses and 
the DNS name server modules for accessing those clearing- 
houses. 


A term used in Digital’s DNS name server that refers to the 
collection of all names on the network. The namespace is 
distributed among multiple clearinghouses. 


A unique ID for a namespace that distinguishes it from all 
other namespaces. 

See Network Application Support. 

See National Institute for Standards and Technology. 

United States government body that provides assistance for 


standards making. Formerly the National Bureau of Stand- 
ards. 


multitasking tim National Institute for Standards and Technology 
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NAU Network addressable unit. The boundary of an IBM SNA 
network. Logical and physical units are examples of NAUs. 


NBS National Bureau of Standards. See National Institute for 
Standards and Technology. 


NBS-AS2 National Bureau of Standards, Abstract Syntax 2. An abstract 
syntax developed by the NBS (now NIST) to make a file di- 
rectory an entry that appears like a file, allowing remote 
FTAM systems to request a directory of files. 


NCL See Network control language. 

NCP See Network Control Program. 

NCS See Network Computing System. 

NET Network Entity Title or NetBIOS Sniffer Analyzer abbrevia- 


tion for NetBIOS packets or OSI network layer network en- 
tity title. The network entity title is one of several possible 
network addresses on a particular node. The NET is a per- 
manent, unambiguous reference to the node, similar to the 
DECnet Node ID. 


NETACP Network ancillary control process. A type of VMS process 
that provides the link between the user of the network and 
the I/O drivers (NETDRIVER). 


NetBIOS Network Adapter Basic Input/Output System. A Network 
protocol that allows a client program to find a server proc- 
ess and communicate with it. Similar to Named Pipes. 


NETDRIVER A VMS process that provides read and write services over 
the network for DECnet applications. NETDRIVER would 
then communicate with a physical driver that used Ether- 
net, DDCMP, CI, or another supported data link protocol. 


NetWare The networking components sold by Novell. A collection of 
data link drivers, a transport protocol stack, workstation 
software, and the NetWare operating system. 


NetWare for VMS Program for Digital’s VMS operating system that makes the 
VAX look like a NetWare server. Ancestor of Portable Net- 
Ware. 


NAU im NetWare for VMS 
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network address 


Network 
Application 
Support 


Network 
Computing System 


Network Control 
Language 


Network Control 
Program 


Network File 
System 


Network 
Information 
Services 


Network Loadable 
Module 


network selector 


Network Services 
Protocol 


NewS 


NFS 


NFT 


nibble 


The number of the network the user is on. Each network 
(data link) in an internetwork has a number assigned to it. 
The full address of a station is the network address plus the 
local address of the node on that network. 


Digital standards to allow everything to work with every- 
thing. Similar in scope to IBM’s SAA. 


Apollo’s computing architecture. The Digital RPC mecha- 
nism is derived from the NCS RPC architecture. 


Command line interface to DECmcc. 


A Digital user interface to the network management layer of 
the Digital Network Architecture. 


A distributed file system developed by Sun Microsystems 
and widely used on TCP/IP systems. 


See Yellow Pages. 


Program vn NetWare 386 that when loaded becomes a part 
of the operating system. 


The part of an address at layer N that selects a particular 
user at layer N; in other words, the address of the next 
layer. 


DECnet transport layer protocol. 


Network Extensible Window System. A windowing environ- 
ment from Sun Microsystems based on the Postscript lan- 
guage and a proprietary window control protocol. 


See Network File System. 


Network file transfer. An interactive utility that gives access 
to remote data using the DAP protocols. 


Half a byte. 


network address |i» nibble 
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NIC 


NICE 


nickname 


NIS 
NIST 
NLM 


NMCC/DECnet 
Monitor 


NML 


node 


nonexclusive 
(read) lock 


nonpersistent 
binding 
nonrestricted token 
nonrouting node 


NPID 


NIC tim» NPS 


Network Information Center. A facility located at the Stan- 
ford Research Institute that administers Internet addresses. 


Network Information and Control Exchange. A DECnet proto- 
col used for the exchange of network management informa- 
tion. 


A way of referring to a DNA Naming Service namespace. 
The nickname is locally maintained on a node and trans- 
lated into the NSCTS for interaction with name servers. 


Network Information Services. See Yellow Pages. 
See National Institute for Standards and Technology. 
See Network Loadable Module. 


Network Management Control Center. A precursor to DEC- 
mcc for network management. Includes multiple open win- 
dows, historical data display, alarm definition, and other 
features. 


Network Management Listener. A VMS process that commu- 
nicates with a Phase IV network management interface on 
another node to provide information about the local node. 


An individual item in a set. An Ethernet node, for example, 
is a device attached to the cable with a transceiver, includ- 
ing a repeater, bridge, or computer. A file system node is a 
directory or individual file. 


A type of lock on a file that permits other users to read in- 
formation but prevents any write operations. 


A style of binding in remote procedure calls where the con- 
nection is set up and torn down every time the remote pro- 
cedure is called. 


FDDI token in asynchronous mode available to all users. 


See end node. 


Network Layer Protocol Identifier. Used in the ES-IS proto- 
cols in the OSI network layer. 


NMCC protocol server. A portion of the NMCC software that 
interfaces to the network. 
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NPSI 


N(R) 


N(S) 


NSAP 


NSCTS 


NSDU 


NSEL 


NSFnet 


NSP 


NSUID 


object 


OCC 


office 
communications 
cabinet 


OLTP 


Network Packet Switching Interface. A type of IBM software 
that allows SNA data to be carried over an X.25 network to 
another SNA environment. 


Receive sequence number. LLC field that indicates the se 
quence number of the last packet received. 


Send sequence number. LLC field that indicates the se 
quence number of the packet being sent. 


Network Service Access Point The access point to the net- 
work. 


See Namespace Creation Time Stamp. 


Network Service Data Unit. From OSI Network Service Defi- 
nition. 


See network selector. 


National Science Foundation network. A research network es- 
tablished by the NSF to give access to supercomputer and 
other computing facilities. 


See Network Services Protocol. 


Namespace unique identifier. It is possible (though some- 
what unusual) to have multiple DNS namespaces on a sin- 
gle network, hence the need for a unique identifier. Most 
operations use the default namespace. 


An entry in the DNA Naming Service. The simple name of 
the object, together with the names of all parent directories, 
form a unique full name in the namespace. 


See office communications cabinet. 


A DECconnect cabinet that provides the hub for up to 128 
offices (or faceplates). 


Online Transaction Processing. A term muddied by market- 
ing department. Basically means an application that exe- 
cutes lots of small transactions rapidly. 


NPS! imp ~OLTP 
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LLL 


ONC 


Open Network 
Computing 


Open Software 
Foundation 


Open Systems 
Interconnection 


O/R Address 


OSAK 


OSF 
OSI 


outgoing 
connection timer 


Pl 
P2 
PAB 


Pack 


packet 


Packet 


Assembler/Disassem 


bler 


Packet Exchange 
Protocol 


See Open Network Computing. 


Sun marketing term for the family of protocols that in- 
cludes the Network File System. 


Nonprofit organization founded by Digital, IBM, and four 
other vendors to develop specifications for an open software 
environment. 


The ISO’s standards for a heterogeneous, open network ar- 
chitecture. 


Originator/recipient address. A valid X.400 address. 


OSI Applications Kernel. A set of program libraries sold by 
Digital as the interface to layer 5 of the OSI model. 


See Open Software Foundation. 
See Open Systems Interconnection. 


Session control term. When the session layer issues a con- 
nect request to the transport layer, it starts this timer. If an 
accept or reject indication is not received before the timer 
expires, session control issues a disconnect and informs the 
end user. 


X.400 protocol used between MTAs. 
X.400 protocol used between user agents (IPMSs). 
See Personal Address Book. 


Term used in remote procedure calls for translating data 
from the machine-dependent format into a machineinde- 
pendent format. 


A general term used in networking to refer to a message 
sent to a peer entity in the network. 


Special-purpose computer on an X.25 network that allows 
asynchronous terminals to use the synchronous X.25 net- 
work by packaging asynchronous traffic into a packet. 


An XNS transport protocol that requires each packet to be 
separately acknowledged. 


ONC iim Packet Exchange Protocol 
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packet switching 


PAD 


Paging 


PAM 


PAR 


path 


PBX 


PC-DOS 


PCSA 


PDL 


PDP 


PDS 


A network that has packaged data into packets. A computer 
can handle many more virtual connections with packets 
than it can with dedicated connections (known as circuit 
switching). Packet switching forms the basis for X.25, as 
well as most network-layer protocols. 


See Packet Assembler/Disassembler. 


A memory management technique in a virtual memory op- 
erating system. Only a few parts (pages) of a program are 
actually in memory. When a new part is needed, it is paged 
into memory. 


Protocol assist module. A piece of hardware on a DECSA to 
provide higher performance for protocol processing. 


Positive acknowledgment retransmit. A method of assuring 
reliable communications used by the DDCMP data link pro- 
tocol. 


As a file system concept, the path indicates what set of fold- 
ers or subdirectories a file is stored in. In the networking 
sense, a path is the route a packet takes from the source to 
the destination. The path is a series of data links or hops. 


Private branch exchange. A telephone switch installed at the 
customer premises. Allows the organization to take control 
of many of its telecommunications functions. 


Personal Computer—Digital Operating System. IBM?’s version 
of Microsoft’s operating system. 


See Personal Computing Systems Architecture. 


Page description language. Postscript is an example of a 
PDL. 


Programmable data processor. A series of Q-bus-based 16-bit 
minicomputers manufactured by Digital. 


Premises Distribution System. AT&T cabling system. 


packet switching im» PDS 
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PDU 
PEP 


permanent virtual 
circuit 


Personal Address 
Book 


Personal 
Computing 
Systems 
Architecture 


PEX 


P/FM 


P-G 


Phase IV 


PHIGS 


PHIGS Extension 
to X 
PHONE 


PID 


PIN 


piggybacked 


PDU im piggybacked 


See Protocol Data Unit. 
See Packet Exchange Protocol. 


A circuit kept up permanently, as in the case of a dedicated 
leased line on the telephone network. 


The local directory facility in ALL-IN-1. See also Distributed 
Directory Service. 


Digital architecture for the integration of PCs into DECnet. 


See PHIGS Extension to X. 


PBX/Facilities Management. 
PBX traffic. 


Digital software for managing 


Plenum-Grade. DECconnect abbreviation. Type of cable 
coating suitable for installation in environmental airspaces 
such as heating ducts. 


The current phase of DECnet. 
See Programmer’s Hierarchical Interactive Graphics System. 


Extension to the X Windows System to incorporate 3D 
graphics. 


A VMS program that allows interactive two-way conversa- 
tions over a DECnet. 


Process identification. Used to identify each process run- 
ning on an operating system. The VMS lexical function 
F$PID returns the value of PID. 


Personal Identification Number. A number used on ATM 
and smart cards to verify the identity of the user. 


Added on to. A term used in protocols that require the ac- 
knowledgment of prior packets. The acknowledgment can 
often be piggybacked into the same packet as data headed 
in that direction. 
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ping-pong 


pipe 
PM 


portal 


POSIX 


PostScript 


POTS 


ppm 


PRDMD 


PrE 


presentation 
module 


presentation syntax 


primitive 
a 


print spooler 


A type of transport protocol that requires each packet to be 
individually acknowledged. Before a node can send another 
packet, it must wait for an acknowledgment. 


See Named Pipes. 
See presentation module. 


There may be several different users of the Ethernet service, 
each with a portal, or identification number. Incoming 
packets are then distributed to the appropriate portal. 


Portable Operating System Interface for Computer Environ- 
ments. IEEE-developed standards to provide a common in- 
terface to the operating system, thus making applications 
more portable. 


A page description language used on printers such as the 
Apple LaserWriter and on computer displays used in work- 
stations from companies such as NeXT and Sun Microsys- 
tems. Similar in function to Xerox’s Interpress. 


Plain Old Telephone Service. As opposed to ISDN, Call Wait- 
ing, or any other modern marvels. 


Pages per minute. Rating measure for laser printers. 


Private Directory Management Domain. An X.500 adminis- 
trative entity that is not a public carrier. See ADDMD and 
Directory Management Domain. 


Printer emulation. Digital SNA access routine that allows a 
VAX to emulate an IBM printer. 


The module in DECmcc responsible for the interface to the 
user device. 


A standard method of representing data in a heterogeneous 
environment. The Abstract Syntax Notation 1 (ASN.1) is an 
example of a presentation syntax. 


ISO definition: an element of a service provided by one en- 
tity to another one. 


A software program that accepts several jobs at once for 
printing. The spooler controls access to the printer and 
queues incoming jobs for execution. 


ping-pong iim print spooler 
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PRMD 


PROFS 


Programmer’s 
Hierarchical 
Interactive 
Graphics System 


propagation 
velocity 


propagated updates 


protocol data unit 


protocol sequence 


protocol stack 


PSI 


PSN 


PSTN 


PRMD im PTT 


Private management domain. An X.400 domain. See ADMD. 


Professional Office System. IBM office automation package 
for the VM/CMS operating system. 


Imaging system providing sophisticated capabilities such as 
hidden-surface removal, shading, and depth cueing. 


The rate at which a signal propagates on a wire. Signals 
travel over a wire much like ripples in a pond after a stone 
is thrown in. 


One of two ways in the DNA Naming Service a replica can 
be updated. Propagated updates are immediately sent to 
other replicas. A skulk runs periodically and updates repli- 
cas. 


A layer communicates with its peer by sending packets. 
Each packet has a header that contains information with 
which the peer will work, such as addresses or acknow- 
ledgment requests. It also contains data, the protocol data 
unit, that is passed up to the client of the layer. 


DNA Session Control term to indicate the protocols to be 
used at each layer of the stack to make communication 
practical. 


A set of functions, one at each layer of the protocol stack, 
that work together to form a set of network services. Each 
layer of the protocol stack uses the services of the module 
beneath it and builds on that service. 


Packet-switch interface. Digital software to allow a VAX to 
participate in an X.25 network. Also the name of a com- 
pany that provides commercial TCP/IP services. 


Packet switched network. An X.25 network. 
Public Switched Telephone Network. 


Poste Téléphone et Télégraphe. A government provider of 
communications functions in most European countries. 
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SS 


PU 


public domain 


Q.700 
Q.701 


Q711 


Q.721 


Q.730 


Q.761 


Q.930 


Qbus 
QIo 


Qos 


RARP 


Physical unit. An SNA term used to refer to different types 
of hardware in the network. A 3274 cluster controller is a 
PU type 2 (PU2). 


Intellectual property available to people without paying a 


fee. Most computer software developed at universities is in 
the public domain. 


Polyvinyl Chloride or see permanent virtual circuit. Polyvinyl 
chloride is a type of cable coating unsuitable for environ- 
mental airspaces, but often used in offices. See P-G (Plenum- 
Grade). 


Introduction to CCITT SS number 7. 
The Message Transfer Part of Signalling System number 7. 


Signalling connection control part of Signalling System 
number 7. 


Telephone User Part of Signalling System number 7. 


ISDN supplementary services definition for Signalling Sys- 
tem number 7. 


The ISDN user part of Signalling System number 7. 


CCITT standard for the ISDN user-network interface at layer 
3: 


The peripheral bus used on MicroVAX and PDP computers. 


Queue input/output. Method used for an application to call 
a device driver directly in the VMS operating system. See 
RMS. 


Quality of service. A series of negotiable parameters in X.25 
and OSI network implementations. 


Random access memory. Dynamic memory, sometimes 
known as main or core memory. 


Reverse Address Resolution Protocol. A TCP/IP protocol that 
provides the reverse function of ARP. Used by diskless 
nodes when they first initialize to find their Internet ad- 
dress. 


PU im RARP 
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rep 


RDA 


Rdb 


RDN 


RD PDU 


read-only replica 


ReGis 


register 


Relative Record 
Number 


REM 


Remote Electronic 
Mail 


remote procedure 
call 


Remote Wall 
Enclosure 


REP 


rcp mJ REP 


Remote copy program. An upper-layer TCP/IP service found 
in the Berkeley Unix implementation for copying files. See 
FTP for the Arpanet equivalent. 


Remote Data Access. An international standard for access to 
databases in a heterogeneous computing environment. 


Digital’s relational database management system. Rdb/VMS 
is the primary software, although there is a version for the 
ELN real-time operating system. 


Relative Distinguished Name A name in an X.500 directory. 
It is relative to some well-known root. 


Redirect PDU. From OSI Network Service Definition. Used 
to inform a system to redirect future PDU to another inter- 
mediate system. A primitive form of routing control. 


A DNA Naming Service directory. The read-only replica is a 
copy of the other replicas, but cannot be directly updated. 
See also secondary replica and master replica. 


Remote graphics instruction set. A set of Digital protocols 
used in the VT240 and 241 graphics terminals. 


The DFSCP command that publicizes the availability of a 
file system for remote mounts. See mount. 


Form of variable file access method in DAP. 


See Remote Electronic Mail. 


An MCI Mail account used by companies that have several 
users. 


A set of network protocols that allows a node to call proce- 
dures executing on a remote machine. The Netwise RPC 
Tool, HP/Apollo RPC, and Sun’s NFS RPC are examples of 
such protocols. 


DECconnect wiring concentrator. Used to distribute a mul- 
tilead cable to individual offices or as a twisted pair concen- 
trator for Ethernet. 


Reply to Message Number DDCMP message to force acknow- 
ledgment. 
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SS 


repeater 


replica 


replica set 


Request for 


Comment 


reservation field 


restricted token 


RFA 


RFC 


RFT 


RG-62 


RGB 


ring purge 


RIP 


RISC 


RJ 


An Ethernet device used to connect two or more segments 
of cable together. The repeater retimes and reamplifies the 
signal received on one segment before resending it on all 
other segments. 


A copy of a DNA Naming Service directory. See master, sec- 
ondary, and read-only replicas. 


A list of all DNA Naming Service clearinghouses that store 
copies of a particular directory. 


A document issued in the TCP/IP Internet environment. 
Some RFCs become part of the TCP/IP standards. 


A field in token ring packets that allows a node to inform 
the active monitor it has data of a certain priority to send. 


A special mode of asynchronous access in FDDI where the 
bandwidth is dedicated to an extended dialogue between 
two users. 


record file address. The unique address of a record within a 
file. Used in Digital’s RMS file system. 


See Request for Comment. 


Revisable form text. A version of IBM’s Document Content 
Architecture. 


Grade of coaxial cable. 


Red, green, blue. A method of representing colors as a mix 
of red, green, and blue. Used on monitors. 


A token ring packet that clears the network of data, similar 
in function to the ARCNET reconfiguration burst. 


See Routing Information Protocol. 


Reduced instruction set-computer. Generic name for CPUs 
that use a simpler instruction set than more traditional de- 
signs. Examples are the IBM PC/RT, Pyramid minicomput- 
ers, and the Sun SPARC workstations. 


Reject. A protocol data unit type in the OSI transport serv- 
ice. 


repeater im RJ 
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RJi1 


RJE 


rlogin 


RMS 


RNR 


root 


root directory 


ROSE 


rotary 


router 


router hello 


routing directory 


Routing 
Information 
Protocol 


Standard modular jack developed by AT&T. Used for tele- 
phones and data communications. Being replaced by the 
RJ45, which is the same size but has more wires. 


Remote job entry. Facility for submitting a job to a com- 
puter for execution. Card readers were early RJE stations. 
Usually means software that emulates RJE stations. 


Remote login. Berkeley TCP/IP command to log onto a re- 
mote node. 


Record management services. A common I/O interface for 
VMS used for access to local data via QIO calls and remote 
data via the DAP protocol. 


Receive Not Ready. HDLC frame. 


Unix superuser. The one account on a Unix system that has 
privileged access. 


The top of the DNA Naming Service namespace. 


Remote Operations Service Element OSI protocol for remote 
procedure calls. Also the name of the developer of ISODE. 


Multiple instances of a service all accessible using one ad- 
dress. The service provider intercepts all requests for that 
address and farms them out to a specific instance. A com- 
mon example of a rotary is when several outgoing lines are 
available for a dial-out service. Rather than make the user 
ask for each line by name, a rotary service connects the user 
to the first available line. 


Dedicated hardware used to route traffic on a network. The 
alternative is to use a portion of a general-purpose system 
such as a VAX. 


DECnet packet used by routers to let other nodes on the 
network know they are operating. 


A database maintained by the network layer to determine 
which paths to use to get to particular networks. 


Several different protocols used in Novell’s NetWare, 
TCP/IP, and Xerox’s XNS to inform computers on a network 
of any changes in the topology of the network. 


RJ11 mp Routing Information Protocol 
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ss SD 


Routing Table 
Maintenance 
Protocol 


routing tables 


RPC 


RPC specification 


RPC Tool 


RR 


RRF 


RRN 


RS-232-C 


RSA 


RSADSI 


RSM 


RSTS 


RSX 


AppleTalk protocol for the maintenance of routing tables. 


A directory maintained by the network layer that contains 
the address of nodes on the internetwork and how to reach 
them. 


See remote procedure call. 


The information prepared by a programmer as input to the 
RPC Compiler. The specification informs the compiler 
which procedures will be distributed. 


The RPC mechanism sold by Netwise, including the RPC 
compiler. 


Receive ready. An LLC field indicating the sending node is 
ready to receive data. Sometimes also stands for request re- 
sponse protocol. 


Response Requested Flag LAT flag set by the slave request- 
ing another packet from the master. 


See Relative Record Number. 


A physical interface standard used frequently for connecting 
asynchronous devices such as terminals. Developed by the 
Electronic Industries Association to define the electrical and 
mechanical link between a DTE and a DCE. 


Rivest, Shamir, and Adleman. The developers of a public key 
authentication technology that forms the basis for the Digi- 
tal security services. 


RSA Data Security, Inc. The firm started by Rivest, Shamir, 
and Adleman to capitalize on their patents. 


Remote Systems Manager. Digital software for managing re- 
mote MicroVAX computers. 


Resource-sharing timesharing system. PDP-based operating 
system. 


Another PDP-based operating system. VMS systems running 
in compatibility mode are able to execute RSX-executable 
images. 


Routing Table Maintenance Protocol iim RSX 
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RTL 
RTMP 
RT/PC 


RU 


RWE 
SA482 


SAA 


SABME 


SAF 


SAP 


SAS 


SASE 


Satellite 
Equipment Reom 


SCA 


SCCP 
SCP 


RTL imp SCP 


Run-Time Library. 

See Routing Table Maintenance Protocol. 

IBM 32-bit workstation based on an RISC architecture. 
Request unit. A part of IBM’s SNA architecture. A series of 
request units are sent from one session participant to the 
other, then processed by upper layers of the protocol stack. 
See Remote Wall Enclosure. 


Digital disk cluster with 2.5 Gbyte of capacity. 


Systems Application Architecture. IBM architecture to pre 
sent common user, communications, and programming in- 
terfaces across multiple hardware platforms and operating 
systems. 


Set Asynchronous Balanced Mode Extended. Type of frame 
used in the LLC operation. 


System Authorization Facility. A family of IBM security 
products. 


Service Advertisement Protocol or See service access point. The 
Service Advertisement Protocol is a NetWare protocol. 


See Single Attachment Station. 


Specific application service element. Application layer con- 
cept in the OSI network architecture. Refers to special-pur- 
pose services such as the job transfer and manipulation 


(JTM) facility. 


DECconnect wiring concentrator. The Satellite Equipment 
Room consists of patch panels for high- and low-speed data 
and voice communications as well as active devices such as 
terminal servers, repeaters, DELNIs, and DEMPRs. 


System Communication Architecture. The Digital architecture 
for Clusters. 


Signalling connection control part. See Q.711. 


Server Control Procedure or Session Control Protocol. 
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rr 


SCS 


SCSI 


SDLC 


SDU 


search path 


secondary replica 


semaphore 


Sequenced Packet 
Protocol 


sequence number 


SER 


server 


server message 
block 


server stub 


System communication services. Software services used in a 
VAX Cluster to provide internode communication. SCS is 
the lowest level of the System Communication Architecture. 


Small computer standard interface. Pronounced “scuzzy.” A 
standard for connecting disk drives to disk controllers, used 
typically in small multiuser computers. 


Synchronous data link control. IBM’s data link protocol used 
in SNA networks. 


See Service Data Unit. 


A mechanism in DOS, Unix, and other operating systems 
that allows a user to specify a command without knowing 
which directory it is stored. The operating system will 
search each of the directories in the search path for the 
command until it finds the file. 


A DNA Naming Service replica capable of updates and ob- 
ject or soft link creations but not child directory creation. 
See also master replica and read-only replica. 


A synchronization mechanism operating systems. 


XNS protocol for reliable transfer of data at the transport 
layer. 


A unique number for every packet on a particular connec- 
tion maintained by a reliable transport layer service. The 
sequence number allows the transport layer to see if any 
packets were lost or delivered out of sequence by the under- 
lying network and data layers. 


See Satellite Equipment Room. 


A program on a computer that provides services to worksta- 
tions. File, database, print, and communications are just a 
few kinds of servers. 


Microsoft protocol for data access which sits on top of Net- 
BIOS. 


A piece of software generated by the RPC Tool. The server 
stub emulates the calling application program to the remote 
procedure on the server. 


SCS im) server stub 
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service access point 


service class 


service data unit 


session 


Session Control 
Protocol 


SGML 


shell 


Single Attachment 
Station 


SIXEL 


skulker 


slot 


SMB 


SMP 


The address for the user of a service. 


A concept in the LAT architecture to allow extensions for 
specific groups of applications, such as interactive terminals 
or windowing workstations. 


The information a layer accepts from its client and sends 
over the network. Contrast with header or control informa- 
tion. 


Networking term used to refer to the logical stream of data 
flowing between two programs communicating over a net- 
work. Note that there are usually many different sessions 
originating from one particular node of a network. 


DNA session layer module. Provides name-to-address trans- 
lation, process addressing, and access control. 


See Standard Generalized Markup Language. 


A term that usually refers to the user interface on an operat- 
ing system. On Unix systems, the C shell or the Bourne 
shell are the primary user interfaces. Contrasts with the 
kernel, which interacts with the computer at low levels. 


FDDI term for a station attached to the ring via a concentra- 
tor. 


A standard format used for bit-mapped images. Comple- 
ments ReGIS, which is a Digital format for line-oriented im- 
ages. 


A term used in Digital’s DNA Naming Service. A skulker is 
a background process that assures that all replicas of a por- 
tion of the namespace are consistent with the master por- 
tion. 


An entry in a fixed-size table. Also a sublayer in the Local 
Area Transport architecture that allows multiple users to 


share a single datagram packet, each occupying a separate 
slot. 


See Server message block. 


See Standby Monitor Present or Symmetric multiprocessor. 


service access point |1m SMP 
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SMS 


SMT 


SMTP 


SNA 


SNADS 


snail mail 


SNAP SAP 


Sniffer 


Sniffer Network 
Analyzer 


SNP 


socket 


soft link 


SOH 
SOM 


source address 


Site Management Station. A bundle of products for an early 
version of DECmcc, including the NMCC/VAX ETHERnim, 
LAN Traffic Monitor, Terminal Server Manager, and Remote 
Bridge Management Software. 


See Station Management. 


Simple Mail Transfer Protocol. The TCP/IP protocol for a 
message-handling system. 


See System Network Architecture. 


SNA distribution services. An architecture used for transfer- 
ring messages in an SNA environment, similar to X.400. 


The traditional postal service. 


Subnetwork Access Service Access Point. A special form of 
Service Access Point where the first 5 bytes of the informa- 
tion field in the Logical Link Control data serves as the pro- 
tocol identifier. 


A network analyzer made by Network General. The Sniffer 
was used to produce the screen dumps of network packets 
in this book. 


Network General product used to monitor many different 
upper- and lower-layer network protocols. 


Sequence Numbers Packet. DECnet/OSI Phase V packet used 
to keep track of link state packets. 


An entry point to a program. User programs communicate 
with transport providers such as UDP or TCP by means of 
sockets. Each user typically has a separate socket. 


An entry in the DNA Naming Service that points to another 
part of the namespace. The soft link is an alias for another 
name. 


Start of header. The beginning of a DDCMP message. 
Start of message. 


The origin of a data packet on a network. 


SMS im) source address 
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SPARC 


spool 


SPP 


SQL 


SRC 


SS7 


SSAP 


SSCP 


standard 


Standard 
Generalized 
Markup Language 


standby monitor 


Standby Monitor 
Present 


star coupler 


station 
management 


Scalable Processor Architecture. A reduced instruction set 
(RISC) processor developed by Sun and licensed by several 
vendors including AT&T and Texas Instruments. Used in 
the Sun Sparcstation family of workstations. 


A place for a fast device (such as a software program) to 
leave data for later processing on a slow device (such as a 
printer). 


See Sequenced Packet Protocol. 
See Structured Query Language. 


Source address. Sniffer Analyzer abbreviation for the 
source data link address. 


Signalling System 7. Protocol related to ISDN. Directs how 
the interior of an ISDN network is managed. 


Source service access point. Address of the user of a service. 
See also DSAP. 


System services control point. A network addressable unit in 
IBM’s SNA architecture. Resides on a mainframe and is the 
central point for that domain of an SNA network. 


A convention that people know about. The nice thing about 
standards is there are so many to choose from. 


ISO standard for the representation of revisable form text. 


Token ring term for a computer waiting for the active moni- 
tor to fail and ready to step in if that happens. Kind of like 
a vice president. 


Packet sent out by a standby monitor every 7 seconds to 
advertise its presence. 


Device used to connect different nodes of a VAX Cluster that 
use the CI bus. 


Part of the FDDI ring. The service that monitor activity and 
exercise overall control. 


SPARC imp station management 
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a 


STE 


stored upstream 
address 


stream 


STREAMS 


Structured Query 
Language 


stub 


subnet 


subvector 


Sun Microsystems 


SunOS 


SVC 


SVID 


Signalling terminal exchange. Equipment in an X.25 net- 
work that forms the boundary of a network. Communica- 
tion between different X.25 management domains is be 
tween STEs using the X.75 protocols. 


Token ring concept. Each node on the token ring stores the 
address of the neighbor from which it receives data. 


An interface to the transport service that allows its client to 
send data in a continuous stream. The transport service 
will guarantee that all data will be delivered to the other 
end in the same order as sent and without duplicates. 


An AT&T mechanism developed for the Unix operating sys- 
tem. STREAMS is a way of connecting a series of software 
modules, letting them send messages to each other. 


International standard language for communicating with re- 
lational database systems. 


A piece of code used in RPC mechanisms. The stub appears 
like the called or calling procedure thus masking the details 
of the RPC implementation from the calling or called proce- 
dures. 


A term used to denote any networking technology that 


makes all nodes connected to it appear to be one hop away. 
In other words, the user of the subnet can communicate di- 
rectly to all other nodes on the subnet. A subnet could be 
X.25, Ethernet, a token ring, ISDN, or a point-to- point link. 
A collection of subnets, together with a routing or network 
layer, combines to form a network. 


Portion of a MAC frame. For example, the token ring com- 
mand to request initialization on the ring contains subvec- 


tors with the adapter software level, upstream neighbor ad- 
dress, and several other fields. 


Makers of workstations and the Network File System. 


Sun Operating System. Sun’s implementation of Unix, 
TCP/IP, and other utilities, libraries, and programs. 


See switched virtual circuit. 
System V interface definition. AT&T-sponsored definition 
used to determine the compatibility of different implemen- 


tations of System V. 


STE 1m SVID 
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switched virtual 
circuit 


symbiont 


symbol 


symmetric 
multiprocessor 


synchronization 


synchronous 


SYS$COMMAND 


SYS$ERROR 


SYS$INPUT 


SYS$LOGIN 


SYS$OUTPUT 


SYS$PRINT 


SYS$SYSTEM 


A virtual circuit that is set up on demand, as in the case of a 
dial-up telephone line or an X.25 call. See permanent virtual 
circuit. 


Symbiosis is the bringing together of two different worlds. 
A symbiont is a VMS process that takes disk files and pre- 
pares them for a printer. 


The smallest signalling element used at the MAC layer of 
the network. The symbol is sent down to the physical layer 
for transmission. In FDDI, a symbol is five code bits at the 
physical layer. 


Term used by Digital for true parallel processing in version 
V of VMS. 


Coordination of tasks among multiple users. Synchroniza- 
tion mechanisms include locking and semaphores. 


An FDDI service class where each requestor gets a preallo- 
cated maximum bandwidth and hence a guaranteed re- 
sponse time. 


A VMS logical name that points to the device that will be 
used to input commands for the Digital Command Lan- 
guage. Points to a terminal device (i.e., tta0:) for an interac- 
tive session or a command file for a batch job. 


A VMS logical name that points to the device used to output 
error messages for the current user. 


A VMS logical name that points to the device used to input 
data (as opposed to commands) for the current user. 


A VMS logical name that points to the default login direc- 
tory for the current user. 


A VMS logical name that points to the device used to output 
results (as opposed to errors) for the current user. 


A VMS logical name that points to the default print queue 
for the current user. 


A VMS logical name that points to the location of system 
executable images. 


switched virtual circuit 11m SYSSSYSTEM 
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—_—— SS 


SYSGEN 


System Network 
Architecture 


T1 
T.4 


T.6 


TCP 


TCP/IP 


Teamdata 


Telenet 
Telex 


Telnet 


TERM 


terminal emulator 


terminator 


terrabyte 


A program in VMS used to alter system-wide parameters 
such as AWSTIME. 


IBM’s networking architecture. 


Digital telephone line operating at 1.544 Mbps. 
CCITT standard for group 3 facsimile transmission. 
CCITT standard for group 4 facsimile transmission. 
See transport connection. 


Telephone Country Code. Part of an X.121 address signifying 
the country being addressed. 


See Transmission Control Protocol. 


Transmission Control Protocol/Internet Protocol. Nonproprie- 
tary network architecture used extensively in Unix and het- 
erogeneous environments. 


‘Time Differential Factor. The difference between the local 
time zone and Coordinated Universal Time (UTC). 


Digital-developed user interface for DSRI compatible rela- 
tional databases. 


Packet-switched network service offered by GTE. 
Messaging mechanism that predates fax or electronic mail. 


Upper-layer TCP/IP service for Arpanet implementations. 
Allows users to log onto remote nodes. 


Terminal. DECconnect abbreviation. 


A program that allows a computer to emulate a terminal. 
The workstation thus appears as a terminal to the host. 


Device on each end of an Ethernet cable to prevent reflec- 
tions. 


One trillion bytes (1,000,000,000,000). 


SYSGEN 1m terrabyte 
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ThickWire 


ThinWire 


THT 


TKS50 
TLI 


token bus 


token ring 


topology 


tower 


TPDU 


TPE 


transaction 


ThickWire im transaction 


Another name for the 10BASE5 standard for coaxial cables 
and Ethernet. 


Thinner and less expensive version of baseband coax cable 
used for Ethernet networks. Also called CheaperNet. 


Token holding timer. Token ring and FDDI term for the 
amount of time a node can transmit data before sending the 
token back out the ring. 


Digital tape cartridge that holds 95 Mbytes of information. 
See Transport Level Interface. 


An alternative to token ring and Ethernet local area net- 
works. Used in the MAP protocols. The token bus uses a 
multiple access protocol, but the device that “owns” the to- 
ken is the only one that can send data. 


A local area network protocol in which computers are con- 
nected together in a ring. A node waits until a token is 
passed around the ring, at which point it may send data. 
When it has finished sending, it releases the token and 
passes it to the next node. See FDDI. 


A network topology shows the computers and the links be- 
tween them. A network layer must stay abreast of the cur- 
rent network topology to be able to route packets to their 
final destination. 


DNA Phase V term for the sequence of protocol identifiers 
and associated address information through which a par- 
ticular module can be accessed. 


See Transport Protocol. Sometimes means twisted pair (or 
toilet paper). 


Transport protocol data unit. A packet of information ex- 
changed between two transport layer entities in an OSI net- 
work. See PDU. 


Unshielded Twisted Pair Ethernet Adapter. DECconnect abbre- 
viation. 


A series of one or more operations that form a logical 
whole. The entire transaction or none of it must take effect. 
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SSS 


transaction agent 


transceiver 


transceiver cable 


TransLAN 


Transmission 
Control Protocol 


transport 
connection 


Transport Level 
Interface 


Transport Protocol 


transport service 


access point 


trap 


TRT 


trunk cable 


The DNA Naming Service module responsible for processing 
requests received from clerks. 


A term used in Ethernet networks. The transceiver is the 
hardware device that connects to the Ethernet media, often 
a piece of coax cable. The transceiver is then connected to 
an Ethernet controller on the host system. 


A cable of up to 50 meters between the transceiver and the 
Ethernet controller. 


A wide-area extended Ethernet bridge manufactured by Vi- 
talink. 


The transport protocol in TCP/IP used for the guaranteed 
delivery of data. 


Virtual channel of communication between two users pro- 
vided by the transport layer module. 


AT&T-developed specification for the interface between the 


transport layer and upper-layer users. 


The OSI transport service classes, numbered from 0 to 4. 
TP4 is a reliable transport protocol. 


The entry point to the transport module for a particular end 
user. 


Programming concept for a block of code executed when- 
ever a specific condition, usually an error, occurs. 


Token rotation timer. Token ring and FDDI term for the 
amount of time the token should take to go around the 
ring. 


Used to distinguish the coaxial Ethernet cable (the trunk) 
from the attachment to the individual node (the transceiver 
cable). 


transaction agent im trunk cable 
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TSAP 
TSR 


TTRT 


TUP 
TW 


twisted pair 


Tymnet . 


UA 


UAF 


UDP 


UI 


UIC 


UID 


UIL 


TSAP ji UIL 


See Transport Service Access Point. 

Terminate and stay resident. 

Target token rotation time. A term used in FDDI to set per- 
formance parameters. The TTRT serves as a measure of ex- 
pected delay and is used, among other things, to set time 
out parameters. 

Teletype. A line-oriented terminal. 

Telephone User Part. See Q.721. 


ThinWire. DECconnect abbreviation. 


A pair of wires (or several pairs of wires) such as those used 
to connect telephones to distribution panels. Twisted pair is 
also being used as a physical transmission medium for Eth- 
ernet, token ring, and other forms of data links. 


Public packet-switched network based on X.25 owned by Mc- 
Donnell-Douglas. 


Universal Modular Jack or Unnumbered Frame DECconnect 
abbreviation. 


Unnumbered acknowledgment or user agent. An unnumbered 
acknowledgment is type of frame used in the LLC opera- 
tion. A user agent is part of a message-handling system. 


User Authentication File. VMS file that holds user informa- 
tion. 


See User Datagram Protocol. 


Unnumbered Information. Type of frame used in the LLC 
operation. 


User identification code. VMS code used to identify every 
user on the system uniquely. 


See unique identifier or User Identification. 


User interface language. A DECwindows concept that allows 
the user interface to be modified for different countries 
without modifying the source code of the program. 
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Ultrix 
Unibus 


unique identifier 


Unix 


unpack 


update listener 


update sender 


update time stamp 


Usenet 


User Datagram 
Protocol 


User Identification 


‘Coordinated Universal Time. 


Version of Unix sold by Digital for VAX computers. 
A peripheral bus used on 11/780 and 8600 VAX processors. 


DNA Phase V service that provides a unique ID over time 
and space. 


Operating system developed and trademarked by American 
Telephone and Telegraph. The word Unix is a pun on the 
Multics operating system. 


Term used in remote procedure calls for translating data 
from the machine-independent form into the form used on 
a particular computer. 


The DNA Naming Service module responsible for receiving 
propagated updates and processing them. See also update 
sender and propagated updates. 


The DNA Naming Service module responsible for immedi- 
ate propagation of updates to other clearinghouses. See also 
propagated updates and skulker. 


An indication of when an entry was last updated. 


Network of Unix users. Informal network of loosely cou- 
pled nodes that agree to exchange information in the form 
of electronic mail and a bulletin board. 


Part of the TCP/IP protocol suite. UDP operates at the trans- 
port layer and, in contrast to TCP, does not guarantee the 
delivery of data. 


VMS method of identifying users. Each user has a User ID 
(UID) and a Group ID (GID). 


Coordinated international 
standard for time. Local time is the UTC plus a time differ- 
ential factor. 


unshielded twisted pair 
See update time stamp. 


Unix-to-Unix copy program. The standard Unix utility used 
to exchange information between any two Unix nodes. 
Used as the basis for Usenet. 


Ultrix im UUCP 
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UUID 


V.21 


V.22 


V.22 bis 


V.23 


V.24 


V.27 


V.27 bis 


V.27 ter 


V.29 


V.32 


V.33 


V.35 


value-added 
network 


value-added 
reseller 


Universal Unique Identifier. Part of the Hewlett- 
Packard/Apollo NCS remote procedure call definition. Simi- 
lar to a DNA UID. 


CCITT standard for 300-bps duplex modem over the general 
switched telephone network. 


CCITT standard for 1200-bps duplex operation over the gen- 
eral switched telephone network. 


CCITT standard for 2400-bps duplex modems over the gen- 


eral switched telephone network. 
CCITT standard for 600/1200-baud modems. 


CCITT standard for the definition of circuits between a DTE 
and DCE. 


4800-bps modem over leased circuits. 


CCITT standard for 4800/2400-bps modem over leased tele- 
phone-type circuits. 


CCITT standard for 4800/2400-bps rnodem over general 
switched telephone networks. 


CCITT standard for 9600-bps modem over 4-wire leased tele- 
phone circuits. 


CCITT standard for a family of 2-wire modems operating up 
to 9600 bps over general and leased telephone circuits. 


CCITT standard for 14.4-kbps modems over leased circuits. 


CCITT physical interface standard for high-speed data trans- 
mission. 


A network on top of a network. 


Company that embeds another company’s products into a 
more sophisticated product. 


UUID \1m™ value-added reseller 
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VAN 


VAR 


VAS 


VAX 


VAX 11/780 


VAX 6200 


VAX 8600 


VAX 8700 


VAX 8840 


VAX Cluster 


VAXeln 


VAX Key 


Distribution Center 


VAXlink 


VAXmate 


VAXNotes . 


VAXPAC 


VAXstations 


See Value-Added Network. 
See Value-added reseller. 


VTX applications service. A library used to develop applica- 
tions on Digital’s VTX software. 


Virtual address extension. Hardware series made by Digital. 


A single Vax processing unit (VUP) processor. Somewhat 


equivalent to a one MIP computer. 


A series of VAX parallel processors with 1-6 CPUs using the 
XMI bus. 


A 4VPU computer. 


A 6-VPU computer that forms the basis for the Bi-bus-based 
VAX computers. 


A parallel processor with four 8700 CPUs. Roughly 24 VPU 
of power. 


High-speed Digital network used to supplement DECnet for 


highly integrated systems. 
Digital real-time operating system. 


Software on a VAX that works with the DESNC encrypting 
Ethernet controller. 


A family of products that allows access from a DSRI-compat- 
ible user interface to a series of IBM-based data repositories. 


Digital 80286-based PC/AT clone, with the addition of an 
Ethernet controller and a different keyboard. 


Digital conferencing software. 


VAX Public Access Communications. Software to allow VMS 
users to initiate outbound modem connections. 


MicroVAX workstations with a 15-inch or 19-inch bit- 
mapped graphic screen and graphics coprocessor. 


VAN timp =VAXstations 
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VBN 


V,E,A tuple 


VID 


VIDA 


view 


virtual block 


number 


virtual circuit 


virtual memory 


virtual terminal 


VISTA 


Vitalink 


VM 


VBN tip ~=VMS 


See Virtual Block Number. 


Verb, Entity, Attribute Tuple. A DECmcc concept used to 
identify a service. The DECmcc dispatch tables keep track 
of the <V,E,A> combinations and the associated procedures 
to call. 


VAX Information Architecture. A related set of software sys- 
tems sold by Digital for data management systems. 


Video. DECconnect abbreviation. 


VAX IBM Data Access. Digital DSRI product that allows ac- 
cess to Cullinet IDMS databases using any DSRI user inter- 
face. 


A database construct that makes a collection of one or more 
tables appear as a single database table. 


Form of variable file access method in DAP. 


A service usually offered at the transport layer. The user of 
a virtual circuit is able to send data to a remote user and 
not worry about putting data in packets, error recovery, 
missing data, or routing decisions. 


An operating system concept that refers to the address space 
of a program. A paging system maps virtual memory to the 
limited physical memory pages as needed. 


A service that allows a user on one system to log onto an- 
other for an interactive session. 


VTX Infobase Structure Tool and Assister. Software package 
for maintaining VTX databases. 


Makers of the TransLAN wide-area Ethernet bridge. 


Virtual machine or see virtual memory. Virtual machine is an 
IBM operating system that permits guest operating systems, 
such as MVS, to reside on top of it. Usually used in conjunc- 
tion with the CMS user interface. 


Virtual memory system. A Digital proprietary operating sys- 
tem for VAX computers. 
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VMSmail 


VMS/SNA 


VOSAK 


VOTS 


VSAM 


VT100 


VT200 


WAN 


watchdog program 


Digital electronic mail utility on the VMS operating system. 


Digital software that allows a VAX with the appropriate syn- 
chronous communications board to function as an SNA 
gateway. 


VAX OSI Applications Kernel. Digital programming library 
for the OSI session layer. 


VAX OSI Transport Services. Digital OSI software that imple- 
ments layer 4 of the ISO reference model. 


Vax processing unit. A Digital measure of processing power. 
The 11/780 is equivalent to one VUP. A VUP is roughly 
analogous to an MIPS, although these numbers cannot be 
compared across product lines because each computer has 
different instruction sets. 


Virtual sequential access method. File organization method 
used in IBM environments for direct access files. Similar to 
ISAM (indexed sequential access method). 


See Virtual terminal. 


A series of Digital terminals. The VT300 series is the current 


family of Digital terminals. VT100 and VT200 are a de facto 
industry standard, meaning that most software packages in- 
clude terminal drivers for these types of terminals. 


Type of terminal developed by Digital for use on VAX com- 
puters. 


Virtual Telecommunications Access Method. An IBM software 
system that provides the interface to an SNA network. 


Virtual Terminal Protocol. ISO standard for virtual termi- 
nals. Similar in function to CTERM and Telnet. 


Videotex. Digital’s Videotex software package. 


Wide-area network. Sometimes also used to mean work 
area network or a small subnetwork for a work group. 


A program, not associated with a user, that watches for spe- 
cific events. A typical watchdog program looks for idle ter- 
minals and logs the user off. 


VMSmail iim watchdog program 
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wide-area bridge 


work group 


WORM 


write lock 


X.3 
X.12 
X.21 


X.21 bis 


X.25 


X.28 


X.29 


X.75 


X.81 


X.110 


X.121 
X.200 


X.208 


A MAC-layer bridge that works on wide-area communica- 
tions links such as T1 and dial-up lines. 


Trendy term for people who work together. Several com- 
puters may be isolated on a small network, known as a 
work group network. Whether anything is accomplished is 
another matter. 


Write once/read many. A type of optical disk that can be 
written locally, contrasted to CD-ROM disk. 


Prevents others from reading or writing the locked data. 
Also known as an exclusive lock. 


CCITT standard for a packet assembler/disassembler (PAD). 
ANSI committee for Electronic Data Interchange 
CCITT standard for circuit-switched networks. 


Use of the synchronous V-series modems over public data 
networks. 


CCITT standard for the interface between a DTE and DCE 
for terminals operating in packet mode and connected to 
the public data network with a dedicated circuit. 


CCITT protocols for an asynchronous terminal to communi- 
cate with an X.3 PAD. 


CCITT protocols for a synchronous DTE (a host) to control 
and communicate with an X.3 PAD. 


CCITT standard for interconnecting separate X.25 networks. 


Internetworking between an ISDN circuit-switched and a 
circuit-switched public network. 


CCITT standard for routing principles on public data net- 
works. 


CCITT numbering plan for public data networks. 
CCITT version of the OSI reference model. 


CCITT version of the OSI ASN.1. 


wide-area bridge jim X.208 
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X.209 


X.211 


X.212 


X.213 


X.214 


X.215 


X.216 


X.217 


X.218 


X.219 


X.220 


X.223 


X.400 


X.402 


X.403 


X.407 


X.408 


X.411 


X.413 


CCITT version of the OSI ASN.1 Basic Encoding Rules (BER). 
Physical service definition for OSI for CCITT applications. 
Data link service definition for OSI for CCITT applications. 


Network layer service definition for OSI for CCITT applica- 
tions. 


Transport service definition for OSI for CCITT applications. 
Session service definition for OSI for CCITT applications. 


Presentation service definition for OSI for CCITT applica- 
tions. 


ACSE definition for OSI for CCITT applications. 


CCITT equivalent of ISO 9066-1: Text communication—reli- 
able transfer. 


CCITT equivalent of the ISO Remote Operations Service Ele- 
ment (ROSE). 


‘CCITT specification of the use of X.200-series protocols in 


CCITT applications. 


Use of X.25 to provide the OSI connection-mode network 
service. 


CCITT standard for message-handling services. 
CCITT Message-handling system: Overall architecture. 
CCITT Message-handling system: Conformance testing. 


CCITT Message-handling system: Abstract service definition 
conventions. 


CCITT Message-handling system: Encoded information type 
conversion rules. 


CCITT Message-handling system: Message transfer system: 
abstract service definition and procedures. 


CCITT Message-handling system: Message store: Abstract 
service definition. 


X.209 timp X.413 
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X.419 


X.420 


X.500 
X.501 
X.509 
X.511 
X.519 
X.520 
X.521 
XDR 


Xerox Network 
System 


XID 


XMI 


Xmodem 


XNS 


XNS Mail 


Transport Protocol 


CCITT Message-handling system: Protocol specifications. 


CCITT Message-handling system: Interpersonal messaging 
system. 


CCITT standard for directory information. 
CCITT Directory: Models. 

CCITT Directory: Authentication framework. 
CCITT Directory: Abstract Service Definition. 
CCITT Directory: Protocol Specifications. 
CCITT Directory: Selected Attribute Types. 
CCITT Directory: Selected Object Classes. 

See External Data Representation. 


A set of upper-layer (layers 3 and 4) protocols, plus some 
applications, typically used in conjunction with Ethernet. 
An alternative to DECnet or TCP/IP. The layer 3 and 4 pro- 
tocols form the basis for Novell’s NetWare. 


IBM product for using X.25 in a heterogeneous environ- 
ment, as opposed to NPSI that uses X.25 as a transport 
mechanism for SNA. 


Exchange identification. An HDLC frame used when a new 
node attaches to the physical medium. The XID frame con- 
tains information such as the node ID or a verification pass- 
word for the connection. 


A 100-Mbps bus used to connect CPUs, BI buses, and mem- 
ory on the VAX 6200 series of parallel processors. 


A set of protocols used for error-free file transfer over voice 
grade lines. Similar to Kermit, Xmodem is used to transfer 
binary and ASCII files from different hosts that are not run- 
ning a common set of networking protocols. 


See Xerox Network System. 


Message-handling service in XNS. 


X.419 imp XNS Mail Transport Protocol 
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XQpP 


Yellow Pages 


Extended QIO processor. A VMS service that receives re- 
quests for data then passes them down to the device driver. 


A set of services in the Network File System that propagate 
information from masters to recipients. Used for the main- 
tenance of system files on complex networks. Yellow Pages 
are also known as the Network Information Services. 


XQP imp Yellow Pages 
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Abort connection request, 130 
Absolutness, 148 
Abstract data type, 383 
Abstract Handle Specification (AHS), 
385 
Abstract syntax, 104, 135, 137, 195 
Abstract Syntax Notation (ASN), 137, 
387 
Accept token, 131 
Access control, 165-66, 174-76, 
230-34, 249, 273, 278, 343, 345, 
383 e 
- see also Interactive login; Proxy 
login; Security 
Access Control Facility (ACF), 250, 
383 
Access control list (ACL), 230, 237, 
383 
Access control set (ACS), 163, 166-67, 
383 
creation and propagation of, 
167-68 
Access dispatch table, 358 
Access message, 252, 256, 260 
Access modules, 355, 365, 372, 383 
Access point, 269, 271 
Accounting management, 337 
Acknowledge Transport Protocol 
Data Unit (AK TPDU) see 
Protocol data unit 
Acknowledgment (ACK), 383 
for Network Services Protocol, 
106, 108, 109-110 
for OSI TP classes, 115, 117-18 


Index 


ACP see Asynchronous control 
process 
ACSE see Association Control Service 
Element 
Action commands, 342 
Activity management, 133, 135 
Activity token, 131 
Addresses, 16-17, 27, 60-63, 94, 106, 
316, 342 
network, 127, 143, 145, 159, 340, 
431 
resolution, 125-28, 144, 387 
selection, 128-29 
Adjacency database, 81-82 
Administration Management 
Domain (ADMD), 316, 383 
Advertisement protocol, 152, 154, 
159, 160, 165, 385 
AES see Application Environment 
Specificiation 
AFI see Authority and Format 
Identifier 
AHS see Abstract Handle 
Specification 
Alarms module, 377 
Alias database, 128-29, 146, 385 
Alias entry, 170 
ALL-IN-1, 313, 314, 385 
Allocation, 385 
Allocation attributes message, 264, 
267 
Alter context messages, 197 
Analyzing Sun Networks, 281 
Announcement mode, 215-16 
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Application Entities, 123, 168 | 
Application Environment 
Specification (AES), 385 
Application layer, 136, 137, 386 
Areas, 60-63, 63-68, 387 
ASN see Abstract Syntax Notation 
Association Control Service Element 
(ACSE), 136, 137, 305-306, 383 
Asynchronous alerts flag, 195 
Asynchronous control process (ACP), 
270 
Asynchronous mode, 35-37, 40-41, 
386, 388 
Asynchronous system trap, 387 
Attention slots, 225, 229 
Attributes, 143, 148-51, 155, 173, 278, 
342, 388 
class specific, 150 
global, 150, 151-52 
messages, 252, 256, 264-69 
Authentication, 272-73, 343, 388 
Authentication trailer, 197 
Authority and Format Identifier 
(AFT), 61, 385 


Balun, 24, 389 

Baseband, 21, 389 

BAT see Binary absolute time 

BIH (International Time Bureau), 
185, 390 

Binary absolute time (BAT), 362, 390 

Binary relative time (BRT), 362, 390 

Binary simple name, 149 

Bind message, 193-95, 293, 390 

Bitmap, 256, 292 

Block Data Access, 252 

Boot command, 204, 206 

Bridges, 15, 27-30, 34, 52, 218, 340, 
348, 377, 391 

BRT see Binary relative time 


Caches, 73-76 

CCR see Commitment, concurrency, 
and recovery service 

Certification authority (CA), 178, 393 

Chaining, 177 

Checksum, 70, 79, 115, 120 

Child entity, 340 


Child entries, 145, 166 
Child pointer, 145 
CI Bus, 211 
Clearinghouse, 145, 147, 150, 155, 
159, 160, 166, 394 
background process, 165 
structure and content of, 161-62 
Clear type-ahead flag, 299 
Client stub, 192 
CMIP see Common Management 
Information Protocol 
CMOT (CMIP over TCP/IP), 348, 395 
Collating table, 268-69 
Collector, 164 
Command file submission, 254 
Command line interpreter (CLI), 
367, 394 
Command processor, 245 
Command terminal module, 289, 
292, 293-99 
Command Terminal Protocol 
(CTERM), 287, 288-304, 309, 396 
characteristics, 291 
command terminal module, 
289, 292, 295-99 
foundation protocol, 288-89, 
293-95 
messages, 299-304 
Commitment, concurrency, and 
recovery service (CCR), 136, 393 
Common Management Information 
Protocol (CMIP), 203, 206-207, 
540, 342, 343, 344-48, 394 
Compression, 250, 251, 256 
Condition Values Returned (CVR), 
359, 397 
Configuration management, 337 
Configuration message, 252, 253-54, 
257-58 
Congestion experienced bit, 89 
Connect control message, 108, 111, 
131, 132 
Connection request, 118, 119-21, 137, 
138, 227, 230-34, 396 
Console commands, 201, 204 
Context handle, 359 
Context name, 155, 158 


Index 467 





Continue transfer message, 261-62 

Control flags, 68 

Control message, 252, 256, 261 

Courier protocol, 186-87 

Creation Time Stamp (CTS), 150, 
163, 396 

Credits, 216, 225, 226, 396 

CSMA/CD protocols, 16, 52, 214, 216, 
392 

CTERM see Command Terminal 
Protocol 

CVR see Condition Values Returned 


DAP see Data Access Protocol; 
Directory Access Protocol 
DAP-FTAM gateway, 278, 280-81, 284 
DASS see Distributed authentication 

security service 
Data, 245-84 
Data Access Protocol (DAP), 94, 104, 
123, 125, 247, 248-69, 278, 284, 
292, 397 
extended attributes messages, 
26469 
files, 250 
message exchange, 250-52 
message formats, 253-63 
Database commands, 342 
Database management system 
(DBMS), 268-69, 281-84, 398 
Data Country Code (DCC), 61, 397 
Data delivery function, 68-76 
end systems and caches, 73-76 
hello packets, 71-73, 77 
Data link address, 91, 143, 217 
Data link encryption, 200 
Data link layer, 184-85 
Data message, 252, 259, 262, 293 
Data slots, 218, 225 
Data token, 131 
Data Transfer Facility (DTF), 248, 
406 
Data unit, 273-74, 406 
Data unit identifier (DUI), 70, 87, 
406 
Data waiting flag (DWF), 219, 220-21, 
222, 406 


Date and time attributes message, 
264, 265 
DBMS see Database management 
system 
DCC see Data Country Code 
DDCMP see Digital Data 
Communications Message 
Protocol 
Decision process, 83-86, 97 
basic algorithm, 85-86 
internal databases, 83-85 
DECmcc, 354-67, 399 
enrollment and extensibility, 
367-72 
help system, 369-72 
management data, 363-65 
module execution environment, 
366-67 
modules, 372-77 
processing wildcards, 359-63 
service routines, 365-66 
tuples, 358-59 
DECnet Session Control layer, 103, 
104, 123, 124-30, 137, 144, 179, 
186, 252, 272, 278, 287, 292, 446 
address resolution, 125-28 
address selection, 128-29 
connection control, 26, 124-25 
services, 129-30 
DECtalk, 377, 400 
DED see Dynamically established 
data link 
Deferred delivery, 325 
DELNI see Digital Local Network 
Interconnect 
DFS see Distributed File Service 
DFS Control Program, 269 
DIB see Directory Information Base 
Digital Command Language (DCL), 
248, 398 
Digital Data Communications 
Message Protocol (DDCMP), 14, 
38-42, 200, 288, 398 
messages, 41-43 
operation, 40-41 
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Digital Distributed System Security 
Architecture (DSSA), 179 

Digital Local Network Interconnect 
(DELNI), 23, 400 

Digital Network Architecture (DNA), 
3, 402 

Digital signature, 178 

Digital Standard Relational Interface 
(DSRI), 284 

Directives, 342, 402 

Direct Memory Access (DMA), 38-39, 
404 

Director, 338, 344, 354, 402 

Directory Access Protocol (DAP), 172, 
402 

Directory Information Base (DIB), 
170, 402 

Directory Information Tree (DIT), 
170-71, 173-74, 403 

Directory management domain 
(DMD), 172, 403 

Directory system agent (DSA), 172, 
175, 403 

Directory System Protocol (DSP), 
172, 403 

Directory user agent (DUA), 172, 175, 
177, 403 

Discard state message, 304, 305 

Disconnect initiation, 108-12 

Disconnection request, 130, 405 

Disconnect message, 120, 122, 398 

Disk server, 271, 273 

Distributed authentication security 
service (DASS), 179, 397 

Distributed File Service (DFS), 145, 
247, 269-71, 281, 284, 401, 403 

Distribution lists, 329-32 

DIT see Directory Information Tree 

Djikstra’s Algorithm, 83-86 

DMA see Direct Memory Access 

DMD see Directory management 
domain 

DNA see Digital Network 
Architecture 

DNA Naming Service (DNS), 8, 104, 
123, 128, 137, 148, 170, 179, 
183, 189, 192, 269, 340, 342, 404 

errors, 169-70 


name server, 161-65 
protocols, 152-58 
purpose of, 144-45 
security in, 165-68 
DNA Session Control service see 
DECnet Session Control layer 
DNS see DNA Naming Service 
DNS Clerk, 144, 147, 152-55, 162 
and caches, 161 
operation of, 158-61 
bootstrapping, 160-61 
contacting name servers, 159 
walking the tree, 159-60 
Domain Function Module, 359 
Domains, 60-63, 404 
Domain Specific Part (DSP), 61, 68, 
405 
Drift, 185 
DSA see Directory system agent 
DSP see Directory System Protocol; 
Domain Specific Part 
DSRI see Digital Standard Relational 
Interface 
DSSA see Digital Distributed System 
Security Architecture 
DTF see Data Transfer Facility 
DUA see Directory user agent 
DUI see Data unit identifier 
DWF see Data waiting flag 
Dynamically established data link 
(DED), 91, 406 


E.163, 61 

E.164, 61 

ECO see Engineering Change Order 

EMA see Enterprise Management 
Architecture 

End of file (EOF), 251, 252, 409 

End-of-message (EOM), 297, 409 

End system (ES), 59-60, 64, 71, 73-76, 
91, 408 

Engineering Change Order (ECO), 
407 

Enterprise Management 
Architecture (EMA), 337, 354, 
408 

Entity filter, 343, 345, 362 


Index 469 


eee 


Enumerate attributes exchange, 155, 
156 

EOF see End of file 

EOM see End-of-message 

Epoch, 164, 191, 409 

ES see End system 

Ethernets, 15-16, 95, 106, 211, 409 
basic configuration, 21-25 
bridging, 27-30 
CSMA/CD protocols, 16, 20 
IEEE LANs, 18-21 
multisegment, 25-27 
packet formats, 16-18 

Event dispatcher, 340, 352, 358, 359, 

410 

Event logging, 340, 348-54, 410 

Event report, 340, 342, 345, 352 

Events, 338, 342 
filtering, 353 
flow of, 354 

Event stream, 352 

Exchange ID (XID), 19, 77, 90, 462 


F.69, 61 Y 
FADU see File access data unit 
FAL see File Access Listener 
Fault management, 337 
FCL see Forms and Command Line 
FCS see Frame check sequence 
FDDI see Fiber Distributed Data 
Interface 
Fiber Distributed Data Interface 
(FDDI), 31-37, 52, 214, 412 
File access data unit (FADU), 274 
File Access Listener (FAL), 125, 248, 
249, 252, 412 
File Access, Transfer, and 
Management (FTAM), 3-4, 104, 
123, 247, 269, 273-81, 284, 413 
Digital’s implementation, 278-81 
service classes, 274 
File server, 271, 272 
File Transfer Protocol (FTP), 281 
Filters, 353 
Flow control, 130, 413 
in Local Area Transport, 216 


for Network Services Protocol, 
108, 110 
for OSI TP classes, 115 
Flusher, 89 
Forms and Command Line (FCL), 
354, 359 
Forwarding process, 87-89, 97 
congestion control, 88-89 
partial source routing, 88 
redirection, 87-88 
Foundation protocol, 288-89, 293-95 
Frame check sequence (FCS), 18 
FTAM see File Access, Transfer, and 
Management 
FTAM-DAP gateway see DAP-FTAM 
gateway 
FTP see File Transfer Protocol 
Full lookup, 149 
Full name, 148, 155, 166, 413 
Function dispatch table, 358, 359 
Function modules, 355, 356, 359, 
363, 372, 377, 414 


Gateway Access Protocol (GAP), 248, 
414 

Gateways, 314, 315, 414 

Give token, 131, 134 

Global entity, 341, 414 

Government OSI Profile (GOSIP), 3, 
414 


Hello packets, 71-73, 77, 91, 94 
Hewlett-Packard/Apollo RPC 
mechanism, 192 
Hierarchical Storage Controllers 
(HSC), 211, 213, 246, 281, 416 
High-Level Data Link Control 
(HDLC), 15, 42-51, 52, 200 
error recovery, 48 
frame structure, 46-47 
link initilization, 48 
X.25, 48-51, 114, 115, 415 
Historical Data Record (HDR), 363, 
365, 415 


IBM bisyne, 14, 390 


470 Analyzing DECnet/OSI Phase V 





ICD see International Code 
Designator 

Identifier list (IDL), 230, 417 

IDI see Initial Domain Identifier 

IDP see Initial Domain Part 

IEEE LANs, 18-21 

Indexed Sequential Access Method 
(ISAM), 274 

Information manager, 356, 418 

Initial Domain Identifier (IDI), 61-63, 
417 

Initial Domain Part (IDP), 61-63, 
65-66, 418 

Initiate message, 299, 300 

Input count/check message, 304, 305 

Input process, 297 

Input state message, 304, 305 

Instance identifier, 341 

Integrated Services Digital Network 
(ISDN), 15 

Interactive login, 130 

Intermediate system (IS), 59-60, 64, 
68, 71, 74, 95, 420 

International Code Designator (ICD), 
61 

International Telecommunications 
Union (ITU), 316 

Interpersonal Messaging Service 
(IPMS), 318, 319-24, 419 

Invoke command, 345 

IPMS see Interpersonal Messaging 
Service 

IS see Intermediate system 

ISAM see Indexed Sequential Access 
Method 

ISDN see Integrated Services Digital 
Network 

ISPF Dialogue, 249 

ITU see International 
Telecommunications Union 


Kernel, 356, 421 
Key definition message, 264, 266 


LAD see Local Area Disk Driver 
LAN see Local area network 
LAT see Local Area Transport 
Lifetime indicator, 68 


Link access protocol B (LAPB), 45, 
421 
Link access protocol D (LAPD), 45 
Link service messages, 110, 113, 114 
Link State Packet (LSP), 77, 78-80, 81, 
86, 88, 90, 91, 97, 423 
LLC see Logical Link Control 
Load balancing, 215, 236 
Local Area Disk Driver (LAD), 273, 
421 
Local area network (LAN), 160, 186, 
211, 269, 421 
Local Area System Transport (LAST), 
273, 421 
Local Area Transport (LAT), 4, 13, 
183, 192, 211-41, 287, 292, 293, 
309, 422 
directory access control, 230-34 
directory service, 214, 215, 217, 
222, 234240 
advertisement, 236-37 
caches, 237-39 
multilink nodes and, 236 
service ratings, 236 
flow control in, 216, 223, 225 
nongoals of, 214 
service types, 227-30 
session layer and slot sublayer, 
214, 215, 217, 223-30 
slot types, 225-27 
traffic, 223, 224 
virtual circuit layer, 214, 216, 
217-23, 231 
balancing, 221-22 
timers, 222-23 
Lock manager, 213, 245, 273, 422 
Logical Link Control (LLC), 18, 422 
Logical terminal module, 289-90, 292 
Loop message, 201 
LSP see Link State Packet 


MAC see Medium Access Control 

MAILbus, 313, 314-16, 333, 423 

Maintenance Operations Protocol 
(MOP), 13, 21, 184, 185, 
200-207, 211, 273, 423 
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messages, 201-204 
Major sync point, 133, 134 
Management, 337-77 
Common Management 
Information Protocol 
(CMIP), 344-48 
DECmcc, 354-67 
event logging, 348-54 
model of, 338-42 
Network Control Language 
(NCL), 338, 342-44, 359 
Management Event Notification 
(MEN), 340, 349, 352, 425 
Management Information Control 
and Exchange (MICE), 340, 352, 
425 
Management module, 356, 358, 367, 
369, 424 
Management Specification (MS), 367, 
424 : 
Management Specification Language 
(MSL), 367, 424 
Mass Storage Control Protocol 
(MSCP), 246, 427 
MAU see Multistation access unit 
Maximum ring latency, 32 
Medium Access Control (MAC), 18, 
425 
Memory load message, 206-207 
MEN see Management Event 
Notification — 
Message incarnation field, 237, 238 
Message Router, 314, 425 
Messages, 313-33 
MAILbus, 313, 314-16, 333 
X.400, 316-33 
Message store, 317-18 
Message transfer agent, 317, 325-29, 
330, 425 
MICE see Management Information 
Control and Exchange 
Microsoft Networks/ OpenNet 
Architecture (MS-NET), 271 
Minor sync point, 133 
Modem connect module, 15, 51-52, 
53 
Modem control, 39-40, 424 


Mode message, 293 

Modify characteristics message, 304 

Monitors, 365, 367, 426 

MOP see Maintenance Operations 
Protocol 

Mount command, 269 

MS see Management Specification 

MSCP see Mass Storage Control 
Protocol 

MSL see Management Specification 
Language 

Multicasting, 177, 428 

Multiport transceiver, 23, 428 

Multistation access unit (MAU), 
52-34, 424, 428 

MVS Time Sharing Option 
(MVS/TSO), 249 


Names, 143-79, 215, 342 
internal, 149 
predefined objects, 150 
Name server control, 153 
Namespace, 143, 148, 160, 161, 164, 
429 
structure of, 145-48 
Namespace Creation Time Stamp 
(NSCTS), 148, 429 
Naming service see DNA Naming 
Service (DNS);, X.500 
National Institute of Standards and 
Technology (NIST), 275, 429 
NetBIOS, 271, 430 
Netwise, 197 
Network and Information Control 
Exchange (NICE), 359, 432 
Network Control Language (NCL), 
338, 342-44, 359, 431 
Network File Access Routines, 248 
Network File System (NFS), 281, 431 
Network layer, 6-8, 13, 57-100 
addresses, areas, and domains, 
60-63 
architectural and performance 
parameters, 97-99 
basic data delivery function, 
68-76 
networks and areas, 63-68 
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Phase IV compatibility, 93-96 
subnetwork dependent 
sublayer, 90-92 
subnetwork independent 
sublayer, 76-90 
Networks, 63-68 
DECnet and nonDECnet nodes, 
67-68 
inside private, 64-67 
Network Services Protocol (NSP), 21, 
67, 103, 105-13, 137, 216, 271, 
359, 431 
connection initiation, 108-13 
data packet format, 107 
NFS see Network File System 
NICE see Network and Information 
Control Exchange 
Nickname, 148, 149, 432 
NIST see National Institute of 
Standards and Technology 
Node name, 127, 128, 144 
No operation message, 110, 113 
Novell, 200 
NSP see Network Services Protocol 


Object entry, 145, 166 
Object number, 108 
Open Network Computing model 
(ONC), 200 
Open Software Foundation, 183, 184 
Open Systems Interconnection 
(OSI), 3-4, 8, 67, 183, 434 
session layer, 123, 130-37, 136, 
137, 275, 305, 344 
TP classes, 103, 137, 144-21, 275 
upper layers, 133-37 
Originating packet limiter, 89 
Originator/recipient address (O/R 
Address), 319, 329, 434 
OSI see Open Systems 
Interconnection 
OSI Virtual Terminal Protocol (VTP), 
287, 305-309 
Out-of-band characters, 296 
Out-of-band data message, 300, 302 
Output process, 297-99 


Packet assembler/disassembler 
(PAD), 50-51, 434 

Packet formats, 16-18 

Packet Switch Interface (PSI), 15, 51, 
438 

Parser, 342-43 

Passwords, 166, 178, 273, 343, 345 

Paths database, 83-85 

PDU see Protocol data unit 

Pending alert flag, 195 

Performance management, 337 

Phase IV, 5, 67, 128, 281, 337 

network layer compatibility, 
93-96 

Phase V, 5-6, 67, 95, 128, 152, 281, 
340 

PHIGS see Programmer’s 
Hierarchical Graphics Control 
System 

Pipelining, 106 

Point-to-point protocols, 13-14, 42, 
200, 236 

PostScript, 287, 437 

Preinput process, 296-97 

Presentation layer, 104, 133-36, 137, 
184, 193, 275, 305 

Presentation manager, 359, 377 

Presentation modules, 372, 437 

Print server, 25, 271 

Private Management Domain 
(PRMD), 316, 438 

Professional Office System (PROFS), 
316, 438 

Programmer’s Hierarchical Graphics 
Control System (PHIGS), 287, 
438 

Progress record, 155, 156, 160 

Propagation delay, 187, 189 

Protection attributes message, 267, 
268 

Protocol data unit (PDU), 19, 71, 131, 
438 

Protocol towers, 105, 125-28, 137, 
143, 438 

Proxy login, 124-25, 127, 139, 166, 
250, 256, 269, 270-71, 343, 345 

PSI see Packet Switch Interface 

Public key, 178, 179 
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Qualifiers, 360-62 


Random Access Mode, 251 

Reachable address, 91 

Read characteristics message, 301, 
304 

Read counters message, 201 

Read data message, 299, 302 

Read-Only Memory (ROM), 185 

Receive process, 89-90, 97 

Record Data Access Mode, 252 

Record Management Services (RMS), 
248, 270, 442 

Redundant delete, 149 

Redundant insert, 149 

Referential transparency, 148 

Referrals, 177 

Register command, 269 

Reject message, 120 

Reject slot, 226 

Relational database see Database 
management system (DBMS) 

Release token, 131 

Remote booting protocol, 200 

Remote Operations Service Element 
(ROSE), 136, 172, 184, 442 

Remote procedure call (RPC), 184, 
192-200, 270, 440 

Repeaters, 15, 25-27, 400, 441 

Replicas, 147, 150, 153, 159, 162, 163, 
424, 441 

Reply to Message Number (REP), 40, 
440 

Request program message, 207 

Request/response message, 154 

Resolution, 185 

Response requested flag (RRF), 217, 
219-20, 443 

Return error message, 346-347 

Return results message, 346 

RMS see Record Management 
Services 

ROM see Read-Only Memory 

ROSE see Remote Operations Service 
Element 

Routers, 15, 34, 51, 52, 64-67, 71, 74, 
77, 86, 91, 442 


Routing information, 143, 170, 337 
RPC see Remote procedure call 
RRF see Response requested flag 
Run message, 217, 218, 220, 225 


SAP see Service access point 

SDLC see Synchronous data link 
control 

Security, 127, 130, 145, 165-68, 
177-79, 200, 249, 267, 271, 273, 
337 

Segment length, 70 

Sequence Number Packet (SNP), 77, 
79-80, 97, 106, 447 

Server Message Block (SMB), 271, 
445 

Service access point (SAP), 19, 405, 
446 

Service interface, 338 

Session layer see DECnet Session 
Control layer; Local Area 
Transport, session layer 

Simple Mail Transfer Protocol 
(SMTP), 316, 447 

Simple name, 148, 149 

Sinks, 338, 349, 352, 353, 410 

Skew, 185 

Skulk, 147, 150, 163-64, 183, 446 

SMB see Server Message Block 

SMP see Symmetric multiprocessor 

SMTP see Simple Mail Transfer 
Protocol 

SNA Distribution Services (SNADS), 
316, 447 

SNAP see Subnetwork access point 

SNP see Sequence Number Packet 

Soft link, 145-46, 155, 160, 166, 170, 
447 

Solicitation mode, 215-16 

Solicitation protocol, 152, 154, 159, 
160, 165 

Solicit servers request, 189-90 

SOM see Start-of-message 

Spanning tree algorithm, 28 

Spreader, 164 

SQL see Structured Query Language 

SQL call, 197, 283 

Square root limiter, 89 


474 Analyzing DECnet/OS!I Phase V 





Start message, 217-19 . 
Start-of-message (SOM), 297, 447 
Start read message, 299, 301 
Start slot, 225-27, 232 
Status message, 261, 263 
Stop message, 21, 217, 218 
Stop slot, 226, 232 
Stream Data Access, 252 
Stream interface, 103, 449 
Structured Query Language (SQL), 
283, 449 
Subnetwork access point (SNAP), 19 
Subnetwork dependent sublayer, 
90-92, 97 
autoconfiguration, 92 
static routing, 91-92 
Subnetwork independent sublayer, 
76-90 
decision process, 83-86 
forwarding process, 87-89 
receive process, 89-90 
update process, 77-83 
Subnetworks, 13-53. 
Digital Data Communications 
Message Protocol (DDCMP), 
38-42 
Ethernets, 15-16 
Fiber Distributed Data Interface 
(FDDI), 31-38 
High-Level Data Link Control 
(HDLC), 42-51 
modem connect module, 51-52, 
53 
token ring, 31-38 
Summary attributes extension 
message, 267, 268 
Sun Microsystems, 197, 281, 284, 
449 
Symmetric multiprocessor (SMP), 
245, 246 
Synchronous data link control 
(SDLC), 45, 445 
Synchronous mode, 35-37, 40-41 
System Communication 
Architecture, 246 


System Network Architecture (SNA) 
Gateway, 248 


Target token rotation time (TTRT), 
36, 37, 454 
TCP/IP, 281, 309, 348, 451 
TENT, 85-86 
Terminal class driver, 288, 394 
Terminals, 287-309 
Command Terminal Protocol, 
287, 288-304, 309 
OSI Virtual Terminal Protocol, 
287, 305-309 
Terminal servers, 25, 216, 230-31, 
240, 287, 289 
Termination character, 297 
Terminator echo flag, 399 
ThickWire, 21, 27, 452 
ThinWire, 21, 24, 452 
THT see Token holding timer 
Time Differential Factor (TDF), 185, 
451 
Time protocol, 186 
Time server advertisement, 189-90 
Time service, 183, 340 
need for synchronized, 185-91 
unique identifications, 191-92 
Time stamp, 191, 343, 353, 455 
Token holding timer (THT), 34, 452 
Token ring, 31-38, 452 
initialization and recovery, 37-38 
Token rotation time (TRT), 36 
Top Secret, 250 
TP4 bis, 114, 115 
Transaction Agent, 153, 162-63, 164, 
453 
Transfer syntax, 104, 135, 137, 195 
Transport layer see Network Services 
Protocol (NSP); Open Systems 
Interconnection, TP classes 
Transport protocol class 0 (TPO), 114 
Transport protocol class 2 (TP2), 114 
Transport protocol class 4 (TP4), 103, 
114, 115, 137, 216 
Transport protocol data unit (TPDU), 
115, 452 


‘ 
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Transport service access point 
(TSAP), 120, 453 

TRT see Token rotation time 

True OSI, 9-10 

TTRT see Target token rotation time 


UAF see User Authentication File 
Ultrix, 281, 288, 316, 366, 455 
Unique ID (UID), 191-92, 193, 197, 
340, 345, 455 
Universal Coordinated Time (UTC), 
185, 186, 191, 455 
Unnumbered Information (UI), 19, 
454 
Unread message, 299, 302 
Unshielded twisted pair (UTP), 24, 
455 
Update, 147-48, 150, 162, 168 
Update Listener, 153, 455 
Update process, 77-83 
Link State Packet (LSP), 78-807 
other inputs, 80-83 
Update propagation protocol, 153, 
163-65 
Update Sender, 153, 455 
Upper layers, 8-9, 103-39 
OSI, 133-37 
session layer, 122-37 
DECnet, 123, 124-30 
OSI, 123, 130-33 
transport layer, 
Network Services Protocol 
(NSP), 105-13 


OSI TP classes, 114-21, 135-36 


User agent, 317, 321 

User Authentication File (UAF), 273 
Usernames, 127, 144, 267, 273, 345 
User-to-user dialogue, 103 


UTC see Universal Coordinated Time 


UTC Specifier, 191-92 


VAX Cluster, 211, 213, 246, 281, 284, 
457 

.E,A tuples, 358-59 

Virtual circuit, 105, 108, 115, 118, 
124, 153-54, 159, 186, 195, 275, 
293, 359, 436, 458 


VMSmail, 313, 459 
VMS operating system, 270, 271, 
281, 288, 313, 366 


Wide-area network (WAN), 14, 160, 
185, 218, 459 

Wildcards, 149, 252, 254-55, 281, 343, 
358, 359-63 

Write complete message, 300-301, 
303 

Write message, 300, 303 


X.121, 61 
X.400, 313, 316-33 
distribution lists, 329-32 
Interpersonal Messaging Service 
(IPMS), 319-24, 327 
message transfer agent, 317, 
325-29 
X.500, 168-79, 183 
access control in, 174-76 
components, 172-73 
directory schema, 173-747 
resolving requests, 177 
security, 177-79 
XID see Exchange ID 
X Windows System, 213, 309 
X Windows Terminal, 213, 240, 309 


Yellow page application, 173, 463 
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